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PREFACE 


This  report  was  prepared  as  a  supplement  to  the  Engineering  Data  Com- 
pendium  being  developed  under  the  Integrated  Perceptual  Information  for 
Designers  (IPID)  project.  IPID  is  concerned  with  the  consolidation  and  tech¬ 
nical  presentation  of  perceptual  and  human  performance  data  to  enable  their 
use  as  an  effective  resource  by  designers  of  simulators  and  operational  dis¬ 
plays  and  controls.  It  is  a  multi-agency  effort  supported  by  the  Air  Force, 
Army,  Navy  and  NASA  and  is  managed  by  the  Air  Force  Aerospace  Medical  Research 
Laboratory  at  Wright-Patterson  AFB. 

The  pertinent  research  literature  contains  a  staggering  volume  of 
potentially  valuable  human  performance  data  and  principles  that  have  not  been 
systematically  considered  for  systems  design.  Early  in  the  IPID  project,  the 
domains  of  sensation,  perception,  human  information  processing  and  performance 
were  reviewed  with  respect  to  their  potential  value  to  control  and  information 
display  design.  Forty-five  technical  subareas  were  then  selected  for  detailed 
treatment  in  a  Handbook  of  Perception  and  Human  Performance.  These  subareas 
were  authored  by  some  65  recognized  subject-matter  experts.  The  handbook  is 
to  be  published  in  early  1906  by  John  Wiley  and  Sons  as  a  two-volume  work  of 
approximately  3000  pages.  The  information  in  the  Handbook  was  organized  so 
that  it  would  be  amenable  to  distillation  into  specialized  data  abstracts  or 
entries  for  consolidation  into  an  Engineering  Data  Compendium.  The  emphasis 
of  the  Compendium  is  on  a  usable  presentation  of  behavioral  data  to  design 
engineers. 

In  addition  to  the  basic  research  topics  covered  by  the  Handbook,  the 
following  areas  of  investigation  were  reviewed  by  subject-matter  experts  to 
identify  useful  data  for  extending  the  range  of  the  Compendium  to  the  applied 
research  domains: 

Information  coding,  portrayal  and  format 

-  Target  detection,  recognition  and  identification 

-  Automation  and  allocation  of  functions 

-  Person-computer  dialogue 

-  Feedback,  warning  and  attentional  directors 

-  Human  performance  reliability 

-  Controls 

-  Vibration  and  visual  displays 

This  report  on  Automation  and  the  Allocation  of  Functions  has  been 
produced  as  a  separate  volume  from  the  Compendium  to  enable  its  early  dis¬ 
semination  to  systems  designers.  Timeliness  seemed  especially  critical  given 
the  rapidly  changing  state  of  knowledge  and  technology  in  this  domain. 

This  report  describes  a  general  method  for  allocating  functions  during 
systems  development,  with  particular  focus  on  what  functions  should  be  auto¬ 
matic.  The  method  was  developed  originally  for  the  design  of  controls  in  the 
nuclear  power  industry;  here  it  has  been  redeveloped  for  aerospace  systems. 

As  described,  the  method  applies  broadly  to  allocation  of  functions  during 
systems  acquisition,  and  to  both  control  and  non-control  functions,  but  partic 
ular  attention  is  given  to  the  allocation  of  control  functions  between  humans 
and  automation  (machines) . 


This  method  combines  the  best  features  of  methods  reported  earlier, 
with  improvements  to  make  it  more  practical  and  broadly  useful.  The  method 
includes  three  special  features.  First,  it  provides  for  a  systematic  inter¬ 
action  of  hypothesis  and  test  at  all  stages  of  development.  Second,  it  embeds 
the  allocation  logic  within  the  systems,  design  process,  and  relates  allocation 
decisions  to  other  decisions  of  design.  Finally,  it  provides  a  more  thorough 
treatment  of  human  perceptual  and  cognitive  function,  in  contrast  to  the  focus 
on  psychomotor  issues  which  has  dominated  prior  methods.  Despite  these  improve¬ 
ments  the  allocation  of  functions  is,  and  will  remain,  an  intractable  problem 
in  system  design.  This  method  will  not  provide  an  ultimate  solution.  It  is 
offered  as  one  more  step  toward  the  common  goal  of  engineers  and  engineering 
psychologists:  the  design  of  systems  in  which  humans  and  machines  will  work 
together  with  optimal  effectiveness  and  satisfaction,  serving  human  needs  by 
a  symbiosis  of  human  and  machine  capabilities. 

This  report  is  meant  as  a  user  document,  and  not  a  report  of  original 
research.  The  research  was  reported  by  the  authors  in  earlier  publications, 
which  are  cited  as  references.  Earlier  research  was  supported  by  the  USAEC 
under  Oak  Ridge  National  Laboratory  Subcontract  No.  9027,  and  Department  of 
Energy  Interagency  Agreement  No.  40-550-75. 

This  work  was  performed  by  Essex  Corporation  through  a  contract  with 
MacAulay-Brown,  Inc.  under  Air  Force  prime  contract  F33615-82-C-0513.  Dr. 
Kenneth  R.  Boff  was  the  Air  Force  Aerospace  Medical  Research  Laboratory  Pro¬ 
gram  Manager.  Mr.  Gian  Cacioppo  was  the  Program  Manager  with  principal  sup¬ 
port  by  Ms.  Judy  Williams  for  MacAulay-Brown,  Inc.  The  Essex  Corporation 
Program  Manager  was  Mr.  Clarence  A.  Semple.  Dr.  Robert  Pulliam  was  the  Essex 
Principal  Investigator  for  this  project. 

This  work  was  accomplished  under  AFAMRL  Human  Engineering  Division 
Project  7184,  Task  26,  Work  Unit  06.  The  Program  is  grateful  to  Mr.  Charles 
Bates,  Jr.,  HE  Division  Chief  and  to  Dr.  Thomas  Furness  III,  Branch  Chief,  for 
their  support.  This  effort  was  partially  supported  by  funds  from  the  Air  Force 
Deputy  for  Simulators,  ASD/YW.  We  are  indebted  for  this  sponsorship  to  Mr.  Art 
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SUMMARY 


This  report  describes  a  general  method  for  allocation  of  functions 
during  systems  development,  with  particular  focus  on  what  functions  should  be 
automatic.  The  method  was  originally  developed  for  use  in  the  nuclear  power 
industry,  and  has  here  been  redeveloped  for  use  in  aerospace  systems,  and  in 
conjunction  with  data  of  the  USAF  Human  Engineering  Data  Base. 

The  report  is  intended  for  the  use  of  project  managers,  systems 
engineers  and  system  designers,  as  an  applied  guide  during  the  development  of 
aerospace  systems.  It  provides  a  detailed  procedure  for  allocation  of 
functions  (AOF) ,  a  procedure  to  be  applied  during  the  research,  development, 
test  and  evaluation  (RDT&E)  process.  The  report  uses  a  hierarchical  structure 
in  which  each  of  five  sections  treats  the  AOF  process  at  an  increasing  level 
of  detail,  as  follows:  Section  1  concerns  how  to  use  the  report.  Section  2 
describes  the  RDT&E  process  in  terms  of  the  cyclic  decision  and  test  steps  by 
which  design  proceeds,  and  identifies  those  steps  which  are  critical  to  a 
successful  AOF.  Section  3  focuses  on  one  critical  step  in  RDT&E,  the 
formation  of  design  hypotheses,  and  describes  that  step  in  greater  detail. 
Section  4  focuses  even  more  narrowly  on  a  step  within  design  hypothesis,  and 
identifies  four  sets  of  criteria  which  should  be  applied  in  sequence  to 
assist  AOF  decisions.  Finally,  Section  5  identifies  human-machine  models  by 
which  aerospace  systems  can  be  analyzed  during  systems  design. 

In  each  of  these  sections  the  focus  is  on  the  allocation  of  control 
functions  to  human  operators  or  to  automation.  Nevertheless  the  procedure 
and  logic  of  the  report  will  apply  to  the  more  general  problem  of  allocating 
system  functions  between  humans  and  machines.  An  appendix  is  provided  which 
lists  typical  functions  which  are  performed  well  or  poorly,  by  humans  and  by 
automation. 


5 


GLOSSARY  OF  TERMS  AND  ABBREVIATIONS 


Accessory  functions.  Functions  which  are  not  required  in  normal  operation 
of  the  system.  See  Section  1. 

AOF.  Allocation  of  Functions  (abbrev.) 

Allocation .  When  used  alone,  to  be  read  as  "allocation  of  functions  to  humans 
or  to  machines." 

AOF  hypothesis.  One  of  the  three  design  hypotheses:  Engineering,  AOF, 

Human  Factors.  The  AOF  hypothesis  defines  the  human-machine  interface. 
See  Subsection  3.2. 

AOF  solution.  One  of  the  three  elements  of  the  design  solution:  Engineering, 
AOF,  human  factors.  When  an  AOF  hypothesis  meets  T&E  criteria,  it  can 
be  considered  an  AOF  solution. 

Analogy.  See  Analogous  technology. 

Analogous  technology.  The  intellectual  base  materials,  based  on  past 

technologies,  from  which  all  invention  proceeds.  See  Section  3.0. 

Analysis  phase.  Of  the  systems  development  process,  the  steps  early  in 

design  during  which  the  future  system  is  analyzed  without  formulating 
specific  engineering  details.  Roughly  equivalent  to  the  "functional 
design  phase." 

Automation .  The  mechanization  of  human  control  tasks.  In  this  report 

the  terms  "machine"  and  "automation"  are  used  similarly  in  the  phrase 
"allocation  of  functions  to  humans  or  machine/automation."  The  term 
used  will  be  the  term  which  seems  most  appropriate  for  the  context, 
but  in  general  the  procedures  for  allocating  functions  to  machines  are 
equivalent  to  those  for  allocating  functions  to  automation. 

Balance  of  value  AOF.  The  primary  criterion  by  which  AOF  is  decided:  whether 
automation  or  humans  can  best  perform  the  function.  Not  as  simple  as 
it  sounds.  See  Subsection  4.2. 

Buyers .  Those  who  contract  for  acquisition  of  a  system.  They  may,  or  may 
not  be  the  users . 

C^I .  Command,  control,  communication  and  intelligence.  (also  used  in  the 
literature  are  C^,  C^,  other  abbreviations). 

Cognitive  support.  Meeting  a  specialized  human  requirement  for  information. 
See  subsection  4.4. 


Control  functions.  Those  functions  required  to  control  the  system.  See 
Introduction . 

Decomposition.  The  subdivision  of  a  design  concept  into  achievable  parts. 

A  step  in  the  design  cycle.  See  subsection  2.2. 

Deductive  testing.  Testing  by  intellectual  analysis;  contrasted  to  empirical 
testing. 

Delta.  The  R&D  requirement ;  what  has  to  be  invented  or  developed .  The 

difference  between  existing  technology  and  what  is  to  be  achieved 
by  design. 

Design  decision  cycle.  The  design  decision  logic,  with  feedback  and  iteration 
added . 

Design  decision  logic.  The  underlying  intellectual  process  by  which  all 
design  must  occur. 

Design  decision  process.  The  practical  procedure  by  which  design  of  a 
large  system  must  be  organized. 

Design  documentation  base.  The  central  records  of  a  design  activity. 

Design  hypothesis.  The  three  steps  of  invention,  taken  together:  Engineering 
hypothesis,  AOF  hypothesis,  human  factors  hypothesis.  See  Section  3.0. 

Display  functions.  Functions  required  to  display  system  information  to 
operators  and  decision  makers. 

Documentation.  (1)  Job  documentation:  Procedures,  check  lists,  automated 
procedure  displays.  (2)  Engineering  documentation:  The  design 
documentation  base. 

Embedded  training .  Instructional  program  embedded  in  an  operational  computer 
system. 

Empirical  testing.  Practical  testing  by  applying  elements  of  the  system 
in  actual  or  simulated  use.  Contrasted  to  deductive  testing. 

Engineering  concept.  The  preliminary  assumption  that  a  new  technology  can 
meet  a  user  requirement.  Part  of  the  requirements  statement.  See 
subsection  2.1  and  paragraph  3.1.2. 

Engineering  solution.  One  of  three  elements  of  the  design  solution: 

Engineering,  AOF,  human  factors.  When  an  engineering  hypothesis  meets 
T&E  criteria,  it  becomes  an  engineering  solution. 


End-users .  Those  whose  needs  the  system  is  intended  to  meet.  Not  necessarily 
the  sponsors  of  the  system. 


Engineering,  AOF,  human  factors.  The  step  by  which  a  provisional 
engineering  design  is  invented.  See  subsection  3.1. 


Engineering  concept.  The  general  preliminary  assumption  concerning  technology 
for  a  new  system.  See  paragraph  2. 1.2. 3. 

Engineering  subsystem.  Any  system  can  be  defined  as  consisting  of  an 

engineering  and  a  human  subsystem;  AOF  defines  the  boundary  between 
those  subsystems. 

Function.  A  conceptual  element  of  a  system,  with  inputs,  process  and  outputs. 
See  Section  1. 

Functional  design.  A  conventional  term  for  early  steps  in  design,  during 
which  functions  are  defined.  See  critique  of  this  concept  at 
paragraph  2.5.6. 

HF .  Human  factors  (abbrev.). 

HF  solution.  One  of  three  elements  of  the  design  solution:  Engineering, 

AOF,  human  factors.  When  a  HF  hypothesis  meets  T&E  criteria,  it 
becomes  a  HF  solution. 

Hardware  concept.  Provisional  hardware  design,  stated  in  functional  terms. 

See  paragraph  3.1.4. 

Heuristic .  Exploratory  method  of  solution. 

Human  factors  hypothesis.  One  of  three  elements  of  the  design  hypothesis: 
Engineering,  AOF,  human  factors.  The  step  in  which  a  provisional 
human  organization  is  invented.  See  subsection  3.3. 

Human  engineering.  As  a  generic  terra,  equivalent  to  human  factors  engineering 
More  specifically,  can  mean  just  the  study  of  physiology  in  relation 
to  human  work. 

Human  factors  engineering.  A  discipline  concerned  with  the  design  of  manned 
systems.  It  includes  consideration  of  elements  such  as  conventional 
human-machine  interface  design,  applied  cognitive  science,  and  the 
development  of  human  support  structures:  training,  selection,  job 
design,  career  progression,  job  procedures,  etc. 

Human-machine  interface.  More  commonly:  man-machine  interface.  Defined 
by  the  allocation  of  functions.  See  paragraph  2.3.2. 

Human  subsystem.  A  system  can  be  defined  as  consisting  of  an  engineering 
and  a  human  subsystem;  AOF  defines  the  boundary  between  those 
subsystems.  See  Section  1. 


Hypothesis .  (1)  An  intellectual  step  taken  during  the  process  of  design. 

(2)  The  formalization  of  such  steps  in  design  procedure. 

(3)  Equivalent  to  "invention,"  prior  to  confirmation  by  tests. 

(4)  Inductive  logic  in  design. 

Informational  function.  A  function  which  defines  a  required  flow  of 
information  within  a  human-machine  system.  See  Section  1. 

Iteration .  One  kind  of  feedback  in  the  design  decision  cycle.  Iteration 
includes  both  feedback  to  correct  deficiencies,  and  a  repetition 
of  steps  to  generate  greater  levels  of  detail.  See  subsection  2.5. 

Job  documentation.  Equivalent  to  "procedures."  Not  documentation  as 
stored  in  the  design  documentation  base. 

Life  cycle  systems  management.  The  concept  of  designing  a  system,  and 

forecasting  costs,  for  the  life  of  the  system  from  concept  to  disposal. 

Machine.  See  "automation." 

Material  function.  A  function  which  defines  a  requirement  for  physical 
hardware  in  the  system.  Contrasted  to  "informational  function." 

See  Section  1. 

Model .  As  used  in  Section  5:  A  representation  of  human  and  equipment 
relationships,  expressed  principally  as  a  graphic  diagram. 

Necessary  functions.  Functions  required  to  achieve  minimal  normal  system 
operation.  Contrasted  to  "accessory  functions."  See  Section  1. 

Organizational  design.  The  design  of  an  organization  into  which  the 

principal  operators  and  users  of  a  system  can  fit.  Includes  elements 
such  as  job  design,  a  management  and  supervisory  structure,  personnel, 
payroll,  etc. 

Procedures .  (1)  The  materials  provided  to  guide  humans  In  a  work  or 

operational  sequence:  Written  documents,  check  lists,  automated  or 
embedded  procedures,  maintenance  documentation.  (2)  The  operating 
sequences  themselves . 

Provisional  functions.  Functions  which  have  been  hypothesized ,  but  not 
validated  by  the  design  cycle . 

R  &  D.  Research  and  development  (abbrev.). 

RDT&E.  Research,  development,  test  and  evaluation  (abbrev.).  The  conventional 
expression  for  steps  in  system  development  as  formalized  by  the 
systems  approach  to  design. 

Requirement .  The  original  statement  of  need  for  a  new  system.  See  paragraph 


Roles .  Sets  of  provisional  human  and  machine  tasks,  stated  in  functional 
terms.  "Roles"  evolve  into  "tasks"  as  the  design  approaches 
completion.  See  paragraph  3.2.1. 

Role  of  man.  A  statement  of  how,  in  general,  humans  are  to  be  used  in  the 
new  system.  A  pare  of  the  requirements  statement. 

Software  concept.  Provisional  software,  stated  in  functional  terms.  See 
paragraph  3.1. A. 

Sponsors.  Those  who  establish  the  requirement  and  secure  funding  for 
development  of  a  system. 

State  transitions.  Of  a  system  and  the  states  it  can  assume,  the  process 
of  going  from  state  to  state.  Of  an  aircraft  -  flying,  ground 
operations  are  states;  takeoff  is  a  state  transition.  State 
transitions  create  a  major  requirement  for  control  functions. 

Systems  approach.  The  modern  "whole  system"  approach  to  design.  Not  just 
the  hardware,  but  the  human  subsystem,  support  and  logistics,  all 
deliverable  at  a  time  certain  to  form  an  operational  capability. 

System  users.  End  users,  commanders,  operators,  maintenance  and  support 
personnel. 

T  &  E.  Test  and  evaluation  (abbrev.).  Uses  deductive  tests,  empirical  tests 
and  evaluation  against  criteria.  See  subsection  2. A. 

Tasks .  Specific  actions  performed  in  the  end  system  by  humans  or  machines. 
"Tasks"  emerge  from  the  more  broadly  defined  "roles,"  as  the 
design  nears  completion.  See  paragraph  3.2.1. 

Technical  opportunity.  The  perceived  future  capability  to  which  a  design 
responds.  See  paragraph  2. 1.2. 3. 

Users .  See  "end-users"  and  "system  users." 

Utilitarian  considerations.  The  consideration  that  if  a  human  is  present, 

paid  for  and  not  otherwise  occupied,  he  or  she  should  be  considered  to 
perform  a  function,  even  though  automation  might  otherwise  be  the 
preferred  solution.  See  subsection  A. 3. 
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INTRODUCTION 


HOW  TO  USE  THIS  REPORT 


This  Technical  Report  supports  the  USAF  Human  Engineering  Data  Base 
(HEDB)  by  offering  a  general  method  for  the  allocation  of  system  functions  to 
human  or  automatic  control.  It  can  be  used  by  project  managers,  system 
analysts,  and  system  designers  to  assist  in  determining  the  allocation  of 
functions  during  systems  development,  and  should  be  used  in  connection  with 
data  from  the  HEDB.  Sections  which  follow  describe  a  procedure  for  allocation 
of  functions  (AOF) ,  a  procedure  which  is  closely  linked  to  other  elements  of 
the  design  decision  process,  and  of  the  research,  development,  test  and 
evaluation  (RDT&E)  cycle.  Although  the  focus  is  on  automation  versus  human 
control,  this  procedure  will  apply  to  the  more  general  question  of  allocating 
all  functions  between  humans  and  machines  during  systems  design. 


ORGANIZATION  OF  THE  REPORT 

This  report  contains  five  numbered  sections,  each  of  which  treats  a 
major  aspect  of  the  AOF  process  as  part  of  an  overall  design  decision  logic. 

These  five  sections  are  in  turn  divided  into  decimally  numbered  subsections, 

each  of  which  describes  a  discrete  decision  step,  a  decision  criterion,  or 
an  analytic  tool.  Section  1  is  a  summary;  Sections  2  through  4  are  hierarchical, 
in  that  they  describe  the  design  process,  and  each  subsequent  section  expands  in 
detail  on  a  part  of  the  preceding  section.  Section  5  provides  tools  for 
analysis.  This  organization  is  represented  by  Exhibit  I,  which  shows  the 
logical  subordination  of  subsections,  and  which  can  be  used  as  a  graphic  table 
of  contents.  These  contents  are  described  below: 

Section  1  -  Allocation  of  Functions 

This  section  defines  the  problem  of  allocation  of  functions,  defines 

key  terms  used,  and  summarizes  the  method  which  later  sections  will  describe 

in  detail. 

Section  2  -  Decision  Logic  in  Design 

This  section  describes  how  allocation  decisions  are  embedded  in  the 
systems  design  cycle.  The  systems  development  process  is  explained  in  terms 
of  the  iterative,  logical  steps  which  a  systems  team  must  take  at  every  phase 
of  analysis  and  design.  These  steps  include  both  invention  and  test,  and  must 
be  reiterated  to  correct  errors  and  to  develop  increasing  levels  of  detail. 

Each  of  the  five  included  steps  is  represented  by  a  decimally  numbered 
subsection,  numbers  2.1  through  2.5.  Subsection  2.1,  PREPARATION,  details 
critical  preliminary  actions.  It  is  followed  by  subsection  2.2,  IDENTIFYING 
FUNCTIONS,  which  details  how  the  design  concept  is  partitioned  into  functions, 
and  how  functions  may  be  recognized.  Subsection  2.3,  DESIGN  HYPOTHESIS, 
explains  how  a  set  of  hypotheses  is  formulated  (or  "invented1') ,  concerning  how 
each  function  might  be  accomplished  by  people  or  by  machines.  Subsection  2.4, 


TEST  AND  EVALUATION,  describes  how  these  hypotheses  are  tested,  either 
analytically  or  empirically.  Finally  subsection  2.5,  ITERATION,  explains  the 
reiteration  by  which  hypotheses  are  corrected,  aligned  with  each  other,  and 
decomposed  into  smaller  functions  until  the  design  is  completed  in  detail. 

Section  3  -  Steps  in  the  Design  Hypothesis 

This  section  is  shown  as  subordinate  to  step  2.3  of  the  prior  section, 
and  expands  on  the  design  hypothesis.  This  is  the  critical  inventive  step  in 
design,  and  must  be  examined  in  detail.  During  this  step  a  hypothetical  design 
solution  is  invented  for  each  previously  defined  function.  Invention  consists 
of  three  interrelated  hypotheses,  each  of  which  is  described  in  a  numbered 
subsection.  Subsection  3.1  treats  the  ENGINEERING  HYPOTHESIS,  subsection  3.2 
the  ALLOCATION  HYPOTHESIS,  and  subsection  3.3  the  HUMAN  FACTORS  HYPOTHESIS. 
These  three  steps  are  interactive,  and  are  repeated  until  three  hypotheses  are 
found  which  are  mutually  compatible. 

Section  4  -  Criteria  for  Allocation 

This  section  is  shown  as  subordinate  to  subsection  3.2,  since  it 
supports  that  step  by  identifying  four  criteria  for  the  allocation  hypothesis. 

Exhibit  I 

Organization  Of  The  Report 


Subsection  4.1,  MANDATORY  CONDITIONS,  identifies  cases  in  which  there  is  a 
clear  and  mandatory  choice  between  human  and  machine  control.  Subsection  4.2, 
BALANCE  OF  VALUE  ALLOCATION,  explains  how  the  relative  suitability  of  humans 
versus  automation  can  be  weighed  in  non-mandatory  cases.  Subsection  4.3, 
UTILITARIAN  AND  COST  CONSIDERATIONS,  explains  how  human  utility  and  comparative 
costs  are  taken  into  account.  Finally  Subsection  4.4,  AFFECTIVE  AND  COGNITIVE 
SUPPORT,  identifies  the  purely  human  needs  which  must  be  considered  before  an 
allocation  decision  can  be  final. 


Section  5  -  Human-Machine  Models 

This  section  explains  how  diagrammatic  models  of  human-machine  inter¬ 
action  can  be  used  as  tools  of  analysis  and  design.  Subsection  5.1,  LEVELS  OF 
AUTOMATION,  explores  several  configurations  of  humans  in  relation  to  controls. 
Subsection  5.2,  ELEMENTS  OF  COGNITION,  shows  how  models  can  help  to  identify 
the  cognitive  and  perceptual  limits  of  a  human  operator.  Subsection  5.3, 
ELEMENTS  OF  PERFORMANCE,  broadens  the  issue  to  include  psychomotor  performance 
and  the  effects  of  social  and  affective  settings. 

Appendix  -  Uses  and  Hazards  of  Automation 

The  report  closes  with  a  comparative  list  of  cases.  Several  authors 
have  published  lists,  showing  tasks  which  are  better  performed  by  humans, 
contrasted  with  tasks  better  performed  by  machines.  This  appendix  offers  four 
such  lists,  summarizing  the  literature  on  that  subject.  They  can  be  used  as  a 
verifying  reference,  to  determine  whether  an  allocation  made  using  the  logic 
of  Sections  1  through  5  is  consistent  with  conventional  rules  of  thumb. 

USE  OF  TERMS 

For  convenience,  the  abbreviation  "AOF"  or  the  noun  "allocation"  will 
be  used  in  sections  which  follow,  and  will  always  represent  the  full  phrase 
"allocation  of  functions  between  humans  and  automation." 


SECTION  1 


ALLOCATION  OF  FUNCTIONS 


This  section  introduces  the  problem  of  allocation  of  functions  (AOF) , 
and  the  design  decision  process  within  which  AOF  occurs.  Included  will  be 
the  definition  of  certain  key  terms. 


THE  PROBLEM 

In  most  aerospace  systems  there  is  a  close  sharing  of  tasks  between 
humans  and  machines.  How  these  tasks  are  apportioned  is  determined  by  the 
design  of  the  system  -  the  physical  equipment,  and  the  human  organization;  we 
call  that  apportionment  the  "allocation  of  functions  between  humans  and 
machines."  It  is  one  of  the  most  basic  of  system  design  decisions.  Most  AOF 
choices  are  made  during  the  analysis  and  early  design  phases,  and  they  strongly 
determine  how  well  humans  and  machines  can  work  together  in  performing  the 
system  mission. 

Traditionally,  AOF  decisions  have  been  made  intuitively,  not  as 
deliberate  steps  in  design.  It  was  only  with  the  development  of  systems 
theory  that  AOF  was  formally  recognized,  and  even  now  it  is  often  given  only 
perfunctory  attention.  This  is  in  part  because  there  is  as  yet  no  accepted 
and  reliable  procedure  for  AOF.  The  objective  of  this  report  is  to  provide 
such  a  procedure,  making  use  of  data  from  the  HEDB.  Using  this  procedure  will 
ensure  that  AOF  decisions  are  made  systematically,  and  at  appropriate  points 
during  systems  design.  It  will  assure  that  decisions  are  based  on  appropriate 
criteria,  that  they  are  made  in  interaction  with  related  decisions  of  human 
and  engineering  design,  and  that  they  are  clearly  documented  so  that  they  will 
appropriately  affect  decisions  made  later  in  the  design  process. 


THE  ENGINEERING  AND  HUMAN  SUBSYSTEMS 

Whether  or  not  they  are  systematically  decided,  the  functions  of  a 
system  are  allocated  between  two  major  subsystems  -  the  hardware,  or 
engineering  subsystem,  and  the  human  organization,  or  human  subsystem.  The 
engineering  subsystem  includes  the  major  mission-performing  components  of  a 
system  plus  all  needed  ground  support,  facilities  and  logistics  hardware. 

The  human  subsystem  includes  the  human  organization,  plus  the  selection, 
training,  procedure  development  and  other  utilities  which  give  the  organiza¬ 
tion  direction,  structure,  and  informational  support. 

To  design  these  two  subsystems  requires  two  highly  divergent  kinds  of 
professional  skill.  The  engineering  subsystem  is  developed  by  teams  from  the 
engineering  disciplines,  and  the  human  subsystem  by  teams  from  the  human 
factors  disciplines.  Allocation  of  functions  requires  both  kinds  of  expertise, 
and  it  will  be  successful  only  to  the  extent  that  those  two  teams  remain  in 
close  communication.  This  communication  cannot  be  limited  to  a  "functional 
analysis"  phase.  There  is  no  such  single  phase  in  design.  AOF  is  a  continu¬ 
ing  process  which  requires  the  Interaction  of  engineering  and  human  factors 


disciplines,  from  the  earliest  concept  development  and  throughout  the  RDT&E 
process,  for  the  life  of  the  system. 


WHAT  IS  A  ’'FUNCTION"? 

In  design  engineering,  a  function  is  a  thing  or  event  that  is  needed  to 
achieve  the  mission.  The  concept  of  "functions"  recognizes  that  any  future 
system  can  be  conceived  in  terms  of  a  set  of  subprocesses,  defined  so  far 
as  possible  in  the  abstract,  and  in  terms  of  input  and  output  products.  These 
abstractions  provide  the  tools  for  thinking  about  the  system  during  the 
concept  phase,  and  before  any  hardware  or  human  organization  exists.  Thinking 
in  functional  terms  permits  the  design  team  to  plan  the  elements  which  might 
compose  a  new  system  without  deciding  exactly  how  those  elements  will  be 
built.  A  function  has  at  least  the  following  characteristics: 

A  Function  Provides  an  Interim  Product 


Each  function  produces  an  interim  or  subsystem  product,  and  can  be 
defined  by  its  inputs,  outputs  and  constraints.  The  products  of  a  function 
can  be  either  material  or  informational .  "Produce  thrust"  and  "lower  landing 
gear"  are  material  functions:  "display  velocity"  and  "plan  landing"  are 
informational.  Informational  functions  are  often  overlooked  or  inadequately 
defined  during  functional  analysis. 

Categories  of  Functions 

The  functions  of  a  system  may  be  either  necessary  or  accessory.* 
Necessary  functions  are  required  for  mission  success.  Failure  of  a  necessary 
function  results  in  mission  failure.  Accessory  functions  provide  alternate 
paths  to  accomplishment,  or  add  capabilities  which  are  desirable  but  not 
critically  required.  In  an  automobile,  "propulsion,"  "steering"  and  "speed 
control"  are  necessary,  while  "wipe  windshield"  and  "provide  spare  tire"  are 
accessory  functions.  Some  authorities  identify  control  functions  as  a 
separate  category,  contrasted  to  dynamic  functions.  While  control  functions 
should  be  separately  identified,  they  are  themselves  always  either  necessary 
or  accessory,  and  should  be  so  classified  to  aid  in  tradeoff  studies.  Display 
(or  instrument)  functions  and  af f ector  functions  are  the  subsets  of  control 
functions.  Exhibit  1  (next  page)  suggests  these  relationships. 

There  Are  Many  "Right"  Sets  of  Functions 

There  are  many  possible  ways  to  conceive  a  future  system,  and  even 
more  ways  to  decompose  one  into  functions.  There  is  no  one  "correct" 
functional  design.  Some  are  better  than  others,  but  this  will  change  with 
any  change  in  criteria  or  advance  in  technology.  The  designer's  task  is  to 
discover,  from  among  millions  of  possible  functional  designs,  one  set  of 
functions  which  approaches  the  optimum,  and  which  can  be  achieved  within  the 


*  Alternative  terms  appear  in  the  literature.  These  include  "basic  or 
secondary"  (Demarle  and  Shillito,  1982),  and  "additive  or  multiplicative” 
(Price,  Smith  and  Behan,  1964). 


available  resources. 

Humans  or  Machines? 

The  central  question  is  whether  each  function  will  be  performed  by 
humans  or  machines.  At  first  there  appear  to  be  three  options:  allocate  to 
humans,  to  machines,  or  to  a  combination  of  the  two  acting  together.  At  the 
major  subsystem  level,  most  functions  normally  must  be  allocated  to  some 
combination  of  people  and  machines.  But  these  major  level  functions  must 
then  be  decomposed  by  partition  into  second-,  third-,  and  nth-level  functions 
Ultimately  a  level  of  system  decomposition  will  be  reached  at  which  each 
function  is  allocated  wholly  to  humans  or  wholly  to  machines. 

"Keepine  the  Solutions  at  Ba  " 


Although  each  function  is  an  abstraction,  it  is  necessarily  based  on 
the  designer's  experience  with  real  machines  and  real  people,  and  each 
function  must  be  defined  so  that  it  can  be  achieved  with  real  technology. 

Should  we  try  to  analyze  functions  as  pure  abstractions?  Some  experts  say 
yes.  They  emphasize  that  analysts  should  abstain  from  any  assumption  about 
how  a  function  might  be  accomplished  in  the  real  system.  Keep  the  conception 
abstract,  they  say,  to  keep  your  options  open  and  to  avoid  any  predisposition 
toward  past,  conventional  solutions.  The  designers  should,  they  say,  "keep 
the  solutions  at  bay"  until  a  functional  design  is  complete. 

In  general  this  is  good  advice.  Functions  should  be  defined  in  terms  of 
their  inputs,  outputs,  requirements  and  constraints  -  not  in  terms  of  assumed 
machine  components  or  human  organizations.  The  designers  should  look  for  new 
and  better  solutions,  not  familiar  ones.  Such  an  attitude  is  desirable,  but 
as  an  absolute  it  is  unrealistic.  Real  world  design,  and  in  fact  all  human 


Exhibit  1 

Categories  Of  Function 


Categories 


Subcategories 

Dynamic 

Control 

Affector 

Display 

Propel  Vehicle 

Control 

Speed 

Display 

Speed 

Defog  Rear 
Window 

Turn  Defog 
Off/On 

Display  Defog 
"On”  Light 

Accessory 


Necessary  functions  are  those  within  the  minimum  set  re¬ 
quired  for  completing  the  mission  under  optimal  conditions.  All 
other  functions  are  accessory.  Within  those  categories, 
functions  may  be  further  categorized  as  dynamic  or  control. 
Control  functions  may  be  further  categorized  as  control 
affector  and  display  functions.  Examples  of  typical  automobile 
functions  are  displayed  in  cells  of  the  table. 
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invention,  occurs  by  adaptation.  It  is  inevitable,  and  actually  useful,  that 
as  each  function  is  defined  the  designers  will  begin  to  think  about  how  it 
can  be  realized  with  real  technology.  In  the  sections  which  follow,  we  will 
explain  how  functions  are  actually  defined  by  interaction  among  concrete 
design  hypotheses. 
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SECTION  2 

DECISION  LOGIC  IN  DESIGN 

This  section  describes  how  allocation  of  functions  (AOF)  decisions  are 
embedded  in  other  design  activities,  and  in  the  normal  cycle  of  design 
decision  logic.  It  will  first  describe  the  theory  of  design,  and  will  then 
suggest  five  procedural  steps  by  which  a  good  AOF  can  be  achieved.  Exhibit  2A 
is  an  extract  of  the  original  introductory  exhibit  (Exhibit  I) ,  showing  those 
five  steps  and  the  subsections  in  which  they  are  treated. 

Exhibit  2A 

Five  Steps  of  Design  Decision  Logic 
(From  Exhibit  1) 


THE  THEORY  OF  DESIGN  -  HYPOTHESIS  AND  TEST 

Design  occurs  as  an  iterative  logical  cycle  which  includes  alternating 
steps  of  hypothesis  and  test.  Exhibit  2B  suggests  this  relationship. 

Step  1  represents  an  incompletely  developed  state  of  design  at  a  given  time 
S ( t ) .  Step  2  is  the  inventive  ste;.  in  which  the  designer  hypothesizes  a  way 
to  achieve  seme  element  of  the  design.  This  hypothesis  is  then  subjected  to 
empirical  or  analytic  tests  In  step  3,  to  determine  whether  it  meets  criteria 
and  is  consistent  with  other  elements  of  the  design.  Most  hypotheses  are  net 
immediate!}  acceptable,  and  must  be  modified  or  reconsidered  (step  4)  by 
feedback  to  the  hypothesis  step.  When  a  hypothesis  is  acceptable  it  becomes 
an  element  of  the  developing  design  in  step  5.  Step  6  shows  that  the  design 
then  advances  to  a  more  fully  developed  state  S(t+1). 
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Exhibit  2B 

Theory  Of  Design  -  Hypothesis  And  Test 


Exhibit  2C  compares  the  roles  of  hypothesis  and  test.  These  cyclic 
steps  occur  first  very  rapidly  within  the  minds  of  designers,  and  then  more 
deliberately  as  steps  of  synthesis  and  evaluation  within  the  design  team. 
Finally  they  are  formalized  in  the  cycles  of  development  and  test  required  by 
RDT&E  regulations.  These  cycles  perform  the  following  functions: 

o  They  permit  inductive  logic,  experience,  intuition  and  art  to  be 
applied  to  requirements,  and  then  to  be  checked  by  deductive  logic. 

o  They  permit  the  design  to  be  decomposed  into  manageable  elements  or 
functions  for  initial  solution,  and  then  to  be  tested  as  an  integrated  system. 

o  They  permit  a  design  to  evolve  from  a  set  of  abstract  major  functions 
toward  concrete  engineering  details. 

o  They  permit  continuous  testing  of  the  developing  design. 


Exhibit  2C 

Characteristics  Of  The  Hypotheses  And  Test  Steps  In  Design 


Characteristic 

Hypothesis 

Test 

Process 

Invention 

Synthesis 

Decomposition 

Measurement/Analysis 

Evaluation 

Integration 

Treatment 

Tentative 

Creative 

Confirmatory 

Critical 

Logic 

Inductive 

Deductive 
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THE  PRACTICE  OF  DESIGN  -  A  FIVE-STEP  PROCEDURE 


To  this  point  we  have  considered  theory.  Now  we  will  describe  five 
procedural  steps  which  apply  that  theory,  and  which  are  included  in  all  good 
design  practice.  First  we  will  summarize  these  five  steps  and  then 
subsections  2.1  through  2.5  will  treat  them  in  detail.  Refer  to  Exhibit  2D: 

o  Preparation.  This  step  (detailed  in  Subsection  2.1)  ensures  that 
the  necessary  organization  and  information  are  in  place  before  design 
begins.  It  provides  for  specialist  teams,  specification  of  mission 
requirements,  definition  of  the  role  of  man,  and  a  design  data  base. 

o  Identifying  Functions.  This  step  (Subsection  2.2)  provides  for 
decomposition  of  the  future  system  into  functions,  first  at  a  gross 
level,  and  then  with  increasing  fineness  of  detail. 

o  Design  Hypothesis.  In  this  step  (Subsection  2.3)  a  design 
hypothesis  is  proposed  for  each  function. 

o  Test  and  Evaluation.  This  step  (Subsection  2.4)  subjects  each 
function  to  deductive,  simulation  and  empirical  tests,  first  as 
individual  functions  and  then  as  elements  of  an  integrated  design. 

o  Iteration.  This  step  (Subsection  2.5)  uses  findings  of  the  test 
step  to  control  feedback,  in  order  to  change  the  direction  of  design, 
to  refine  hypotheses,  and  to  generate  finer  levels  of  detail.  This 
feedback  results  in  a  cyclic  repetition  of  steps  2.1  -  2.5  until  the 
design  is  complete. 


Exhibit  2D 

The  Design  Decision  Cycle  (Simplified) 


2.1  PREPARATION  FOR  DESIGN 

This  is  step  2.1  of  the  design  decision  cycle,  as  illustrated  by 
Exhibit  2.1A.  Exhibit  2. IB  shows  the  step  in  expanded  form,  including  three 
major  actions  described  by  paragraphs  2.1.1  through  2.1.3,  following. 


Exhibit  2. 1 A 

The  Design  Decision  Cycle  -  Step  2.1 


2.1.1  Organize  for  Design 

Large  systems  are  designed  by  the  interaction  of  specialist  teams,  and 
the  allocation  of  functions  depends  on  their  coordination.  Coordination 
results  first  from  central  management,  second  from  interteam  communications, 
and  finally  from  an  interdisciplinary  composition  of  teams  and  committees. 
Here  we  are  particularly  concerned  that  human  factors  disciplines  will 
take  part  in  decisions  which  affect  AOF.  To  achieve  a  favorable  organization 
for  design,  the  following  should  be  considered: 

o  Identify  Leaders.  Identify  a  project  director  or  lead  engineer, 
and  leaders  of  specialist  teams.  Specify  who  will  be  responsible  for 
interteam  coordination,  and  for  resolving  conflicts. 

o  Identify  Discipline  Requirements.  Identify  the  professional  skills 
required,  and  specify  required  levels  of  experience.  Include  persons 
with  competence  in  human  engineering,  organizational  design,  training 
and  procedure  development. 

o  Plan  for  Continuity.  Identify  key  people  who  will  remain  with  each 
team  through  several  phases  of  design.  The  composition  of  teams  must 
change,  but  continuity  is  necessary  to  good  design. 

o  Specify  Consultation.  Specify  requirements  for  interteam  consulta¬ 
tion.  Plan  coordination  and  schedules.  If  several  contractors  are 
involved,  require  contractor-to-contractor  coordination  and  documented 
agreements . 

o  Include  System  Users.  Include  experienced  users.  Persons  with 
hands-on  experience  as  users  of  analogous  systems  can  provide 
judgments  concerning  the  practicality  of  design.  "Users"  should 
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include  the  end-users,  those  who  will  operate  the  system,  plus 
builders,  commanders,  pilots,  operators,  maintainers  and  supporters. 


2.1.2  Detail  Requirements 

This  is  the  second  action  shown  by  Exhibit  2. IB,  and  it  includes  four 
subordinate  steps  as  illustrated  by  Exhibit  2. 1C.  These  steps  ensure  a  clear 
understanding  among  the  system  developers,  the  buyers  or  sponsors,  and  the 
end-users  of  the  future  system.  The  buyers  are  a  contracting  office.  The 
sponsors  are  those  responsible  for  acquisition,  in  the  Air  Force  typically  a 
major  air  command.  The  sponsors  may  or  may  not  be  the  end-users.  For 
instance,  a  ground  combat  support  system  might  be  sponsored  by  Air  Force 
Systems  Command,  but  its  end-users  would  be  soldiers  on  the  ground.  The 
following  steps  will  ensure  that  the  requirements  statement  is  complete,  that 
it  represents  the  intention  of  the  sponsors,  and  serves  the  needs  of  end- 
users  . 


Exhibit  2. IB 
Preparation  For  Design 


2. 1.2.1  Define  Mission  Requirements.  Consult  with  the  sponsors  or  end-users 
to  ensure  a  complete  list  of  mission  requirements,  as  follows: 

o  Identify  the  Mission  Profile  and  its  probable  variants.  For  each 
variation,  find  the  permitted  ranges  of  reliability  and  performance. 

o  Query  End-Users  and  operational  commanders  repeatedly,  to  ensure 
that  requirements  are  fully  thought  out. 

o  Be  Ready  to  Expand  or  Change  the  requirements,  based  on  design 
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Exhibit  2. 1C 
Detail  Requirements 


2. 1.2. 2  Define  Constraints. 

o  Look  for  Unstated  Constraints  which  are  understood  by  users,  but  are 
not  expressed  in  writing.  Find  what  cost  limits  apply.  Find  in  what 
environments  the  system  must  perform,  and  what  non-normal  conditions 
may  arise. 

o  Look  for  Informal  Constraints.  In  particular,  watch  for  social, 
organizational  or  political  considerations  which  may  limit  the 
permitted  choices  of  design. 

2. 1.2. 3  Specify  the  Engineering  Concept.  Any  new  system  is  initiated  in 
response  to  a  technical  opportunity.  The  engineering  concept  states  how  that 
opportunity  is  to  be  exploited.  It  ensures  an  understanding  of  what  the 
technical  opportunity  is  believed  to  be,  and  ensures  that  it  has  been 
realistically  evaluated. 

The  engineering  concept  should  be  stated  in  terms  of  the  existing 
(analogous)  technology,  plus  a  required  new  development  or  "delta".  The 
delta  may  range  from  a  minor  exploitation  of  off-the-shelf  components,  to  a 
major  technological  breakthrough.  The  new  system  will  be  developed  by  applying 
the  development  delta  to  the  existing  technology,  to  meet  the  engineering 
requirement . 

o  State  the  Technical  Opportunity. 

o  State  the  Existing  Technology  from  which  the  system  will  be  derived. 


o  State  the  Engineering  Requirement  in  terms  of  quantified  technical 
performance  and  acceptable  ranges  of  performance. 


°  State  the  Development  Delta  in  terms  of  off-the-shelf  technology  to 
be  used,  new  science  or  technology  required,  and  acceptable  ranges  of 
technological  risk. 

o  State  the  Expected  Costs  for  hardware,  operation,  support,  and 
development . 

o  State  Non-Dollar  Resources  which  are  assumed  ,  such  as  existing 
hardware,  facilities  and  organizations. 

o  Describe  Related  and  Interdependent  Technologies,  existing  or  under 
development . 

o  Ensure  That  a  Plan  Exists  for  continued  consultation,  to  modify  the 
engineering  concept,  based  on  lessons  learned  during  development. 

2. 1.2. 4  Specify  the  Role  of  Man.  The  "role  of  man"  is  a  statement  of  how 
humans  will  be  employed  in  a  new  system.  It  is  parallel  to  the  engineering 
concept,  which  states  the  expected  role  of  technology.  The  role  of  man 
statement  reacts  to  the  engineering  concept,  since  it  states  how  the  new 
technology  will  affect  human  participation.  Just  as  the  engineering  concept 
was  defined  in  terms  of  an  old  technology  plus  a  delta,  the  role  of  man  can 
be  defined  in  terms  of  the  human  role  in  a  known  system,  plus  the  organiza¬ 
tional  delta,  or  change  in  the  human  role  which  a  new  system  will  require. 

o  State  the  Role  of  Man  in  terms  of  how  humans  are  used  in  an  existing 
analogous  system,  and  how  the  new  system  will  change  that  role. 

o  State  the  Expected  Levels  of  Automatic  Control,  and  how  human 
control  will  continue  to  be  exercised.  Refer  to  subsection  5.1,  LEVELS 
OF  AUTOMATION,  to  find  appropriate  control  models. 

o  State  the  Expected  Human  Demands  for  skill,  knowledge,  experience, 
complexity  of  decision,  and  speed  of  response.  State  acceptable  ranges 
of  human  performance,  and  humar.  error  rates. 

o  State  the  Level  of  Manning  which  is  assumed.  State  how  skilled 
people  will  be  acquired,  whether  by  selection,  training  or  job 
experience.  State  critical  training  lead  times. 

o  State  the  Acceptable  Balance  between  human  skill  and  automation. 
Describe  relative  human  and  automation  costs  in  dollars  and  procurement 
lead  times. 

o  Specifically  State  any  requirement  for  manned  vehicle  control,  and 
the  rationale  for  that  requirement. 

o  State  How  Human  Control  will  be  maintained  over  automation.  Include 
requirements  for  command  and  policy-level  control,  how  responsibility 
will  be  apportioned  for  catastrophic  human  or  engineering  failure,  and 
requirements  for  key  information  to  be  displayed  or  recorded. 


o  Describe  the  Expected  Structure  of  the  human  organization. 


o  Plan  for  Continued  Consultation,  to  modify  the  role  of  man,  based  on 
lessons  learned  during  development. 


2.1.3  Plan  for  Documentation 


The  engineering  system  is  usually  well  documented  in  its  final  form. 
The  human  subsystem  is  often  less  carefully  documented,  and  the  allocation  of 
functions  (AOF)  is  often  not  documented  at  all,  either  because  AOF  decisions 
are  not  made  systematically,  or  because  the  engineering  documentation  is 
believed  to  be  enough.  Such  documentation  will  not  support  effective  AOF. 
Documentation  is  the  means  by  which  engineers  crystallize  their  ideas,  and 
communicate  them  across  time  and  specialty  boundaries.  AOF  decisions,  in 
particular,  depend  on  communication  between  the  engineering  and  human  factors 
disciplines,  and  upon  the  availability  of  good  formal  documentation  for  both 
the  emerging  engineering  and  human  subsystems.  That  documentation  must  use  a 
common  terminology  and  conventions,  and  must  always  be  accessible  to  all 
members  of  the  design  organization. 

o  Establish  a  Design  Documentation  Base  (DDB)  before  any  design  or 
analysis  begins. 

o  Maintain  Historic  as  well  as  current  design  data.  Record  the 
rationale  for  decisions.  Keep  records  of  directions  taken  in  error, 
so  they  need  not  be  repeated. 

o  Maintain  Separate  Records  of  the  engineering  design,  the  human 
factors  design,  and  AOF  decisions.  Be  sure  those  records  are 
coordinated  at  points  of  interface. 

o  Establish  Requirements  for  each  specialty  team  to  make  and  update 
records.  Do  not  permit  secrecy  or  delay. 

c.  Provide  Access  Systems  to  the  design  data  base. 

o  Identify  Persons  Responsible  for  the  design  data  base  at  each 
organizational  level. 


2.2  IDENTIFYING  FUNCTIONS 

This  is  step  2.2  of  the  design  decision  cycle,  as  illustrated  by 
Exhibit  2.2.  At  this  step  the  designers  decompose  the  system  under  design 
into  functions  which  can  collectively  perform  the  mission.  This  decomposition 
is  progressive  towards  finer  detail,  as  development  proceeds  through 
successive  cycles  of  hypothesis  and  test. 


2.2.1  First-Level  Decomposition 

The  first  step  is  to  define  the  system  in  terms  of  gross  or  major 
functions.  For  instance  it  might  be  defined  into  an  airborne  and  a  ground 
function.  The  actual  initial  decomposition  is  more  likely  to  be  into  1C  to 
20  major  functions,  and  it  can  be  accomplished  in  several  ways: 


o  By  Invention.  Given  an  operational  goal,  the  designers  may  invent 
an  original  set  of  subsystems  or  substates  by  which  the  goal  can  be 
achieved . 


o  By  Partition.  Given  a  prior  system  concept  or  an  analogous  system 
the  system  can  be  broken  down  by  analysis  into  a  useful  set  of  sub¬ 
systems  and  mission  states. 

o  By  Addition  or  Subtraction.  Given  the  functions  of  an  analogous 
prior  system,  functions  may  be  added  or  subtracted  as  required  to 
achieve  the  development  delta  (defined  in  Subsection  2.1). 


Exhibit  2.2 

The  Design  Decision  Cycle  -  Step  2.2 


2.2.2  Recognizing  a  Function 

This  decomposition  often  produces  a  set  of  functions  which  seem  to  be 
equivalent  to  subsystems,  but  a  function  is  not  a  subsystem.  As  defined  in 
Section  1,  a  function  is  a  condition  or  event  that  is  needed  to  achieve  the 
mission,  defined  so  far  as  possible  in  the  abstract,  and  in  terms  of  inputs, 
outputs  and  constraints. 

o  Functions  Are  Not  Subsystems.  For  instance  the  function  "maneuver 
aircraft  on  the  ground"  may  exercise  the  subsystems  of  engine  control 
nose  wheel  steering,  and  rudder  control. 

o  Functions  Are  Not  Tasks.  For  instance  the  function  "maintain  a 
fixed  heading"  includes  the  pilot  task  "enter  azimuth  setting  into 
controls"  and  the  automation  task  "control  rudder  movement." 

o  Functions  Relate  to  System  States  and  Transitions.  During  its 


lifetime  a  system  must  assume  a  series  of  dynamic  and  transitional 
states.  These  include  test,  training,  maintenance,  abnormal  and 
degraded  states,  as  well  as  the  normal  operating  ones. 

o  State  Transitions  define  the  paths  by  which  transitions  occur 
between  states. 

o  Required  Functions  are  those  functions  necessary  to  achieve  the 
minimum  set  of  states  and  transitions  required  for  mission  completion. 

o  Accessory  Functions  are  those  desirable  to  provide  for  abnormal, 
emergency,  test,  training,  or  additional  capabilities. 

o  Control  and  Display  Functions  are  those  required  to  (1)  recognize 
stable  or  unstable  states,  (2)  maintain  stable  states,  (3)  effect 
transitions,  and  (4)  diagnose  failures. 


2.2.3  Operational  Definition  of  Functions 

The  first-level  identification  of  functions  we  have  described  is  purely 
provisional  -  it  is  a  place  to  start.  These  functions  will  normally  undergo 
many  changes  in  response  to  the  needs  of  design,  and  the  final  identification 
of  functions  will  be  the  result  of  that  interaction.  To  see  how  this  happens, 
we  will  look  forward  briefly  into  subsections  2.3,  2.4  and  2.5,  and  observe 
how  functions  are  operationally  defined  during  the  design  cycle. 

o  Design  Hypothesis.  Each  function  that  was  provisionally  identified 
in  the  current  step  (2.2)  becomes  a  design  requirement.  Next,  in  the 
Design  Hypothesis  step  (2.3),  the  designers  will  invent  a  hypothetical 
means  for  performing  that  requirement.  This  will  include  an  engineer¬ 
ing  solution,  a  human  factors  solution,  and  a  hypothetical  allocation 
of  functions  (AOF) .  If  at  this  point  suitable  solutions  cannot  be 
found,  it  may  be  necessary  to  redefine  the  function.  The  designers  may 
go  back  to  step  2.2  and  change  the  identities  of  functions,  or 
decompose  them  into  smaller,  more  manageable  parts. 

o  Test  and  Evaluation  (T&E).  Next  (step  2.4)  the  design  hypotheses 
proposed  at  2.3  are  subjected  to  test.  If  T&E  detects  weakness  in  a 
hypothesis,  further  redefinition  or  repartition  of  functions  may  be 
necessary . 

o  Iteration.  In  the  last  step  (2.5)  T&E  data  are  used  to  initiate 
cycles  of  feedback,  correction  and  repartition.  During  the  feedback 
process,  functions  may  need  to  be  further  redefined. 

o  Repartition.  When  any  function  meets  test  criteria  at  the  gross 
level  of  definition,  it  is  returned  by  the  iteration  step  (2.5)  to 
the  definition  step  (2.2),  to  be  decomposed  into  smaller  functions, 
until  functions  have  been  defined  to  the  required  level  of  detail. 

o  Operational  Definition.  Thus  the  final  definition  of  functions 
results  from  interaction  with  other  decisions  of  design  during  the 


operational  design  process,  and  is  determined  only  in  part  by  the 
provisional  definition  made  at  step  2.2.  That  provisional  definition 
provides  the  input  to  step  2.3,  the  Design  Hypothesis. 


2.2.4  Documentation 

It  is  important  to  maintain  an  auditable  record  of  the  allocation  of 
functions,  including  how  those  functions  are  provisionally  defined  and  later 
modified.  This  record  is  part  of  the  Design  Data  Base,  and  will  be  useful 
to  guide  the  redirection  of  effort  when  design  hypotheses  fail.  When  design 
is  complete  this  record  will  show  the  final  set  of  gross  functions  which 
emerged  from  the  operational  definition  process ,  plus  many  levels  of 
subdivision  for  each  function.  Later  this  record  will  be  useful  for  trouble¬ 
shooting,  retrofit  and  redesign. 


2.3  DESIGN  HYPOTHESIS 

This  is  step  2.3  of  the  design  decision  cycle,  as  shown  by  Exhibit  2.3A. 
Here  the  designers  formulate  a  provisional  design  solution  (or  design 
hypothesis)  for  each  of  the  functions  defined  at  step  2.2.  The  three  elements 
of  the  design  hypothesis  are  (1)  an  engineering  hypothesis,  (2)  an  allocation 
of  functions  (AOF)  hypothesis,  and  (3)  a  human  factors  (HF)  hypothesis  (see 
Exhibit  2.3B).  Each  element  of  the  design  hypothesis  is  proposed  as  a 
provisional  solution  only,  to  be  confirmed  or  corrected  later,  especially 
during  Test  and  Evaluation  (T&E) ,  the  next  step  of  the  design  cycle. 

Of  the  five  steps  in  the  design  decision  cycle,  this  one  is  most 
critical  to  AOF.  Given  this  importance  we  will  come  back  to  it  later  In 
Section  3,  which  will  describe  the  design  hypothesis  as  a  detailed  procedure. 
Here  in  step  2.3  we  treat  it  only  briefly,  as  a  step  In  design. 


Exhibit  2.3A 

The  Design  Decision  Cycle  -  Step  2.3 


The  engineering  hypothesis  is  a  proposed  hardware  design  for  one 
function.  The  designers  respond  to  the  system  requirements,  treating  one 
function  at  a  time,  by  making  a  best  initial  judgment  of  the  engineering 
means  by  which  the  function  should  be  performed.  Each  hypothesis  covers  both 
hardware  and  software.  During  the  early  phases  of  systems  analysis  and 
preliminary  design,  these  hypotheses  are  in  general  terms  only  -  in  terms  of 
equipment  categories  and  generalized  subsystem  descriptions.  Later,  as  the 
design  develops  and  the  functions  are  stated  in  increasing  detail,  the 
engineering  solutions  will  become  particular,  describe  smaller  elements,  and 
be  more  equipment  specific.  Finally  the  point  will  be  reached  at  which  func>~ 
tions  are  partitioned  at  the  lowest  level,  and  the  engineering  hypothesis  will 
specify  particular  components,  software,  and  configurations  of  controls  and 
displays . 

This  hypothesis  is  developed  by  an  engineering  team,  ideally  with  the 
participation  of  human  factors  engineers.  The  products  are  a  generalized 
hardware  assumption,  a  generalized  software  assumption,  an  analysis  of  system 
states  and  transitions,  and  a  list  of  control  requirements. 

2.3.2  The  Allocation  of  Functions  Hypothesis 

The  allocation  of  functions  (AOF)  hypothesis  is  a  proposed  boundary, 
for  one  function,  between  the  engineering  and  human  factors  subsystems.  The 
designers  react  to  the  engineering  hypothesis  just  formulated.  Given  that 
engineering  solution,  they  ask  what  relative  roles  will  be  required  for  humans 
and  machines.  A  hypothesis  is  then  proposed  for  the  optimal  sharing  of  system 
responsibilities  between  engineering  (equipment,  facilities,  software, 
controls,  automation)  and  humans  (users,  commanders,  operators,  maintainers) . 
This  is  the  boundary  between  humans  and  machines,  the  "man-machine  interface." 

During  this  step  the  designers  may  be  forced  to  reject  prior  decisions. 
They  may  reject  a  requirement,  repartition  a  function,  or  modify  the 
engineering  requirement.  As  indicated  by  Exhibit  2.3B,  they  produce  two  lists 
of  control  tasks,  one  to  be  performed  by  humans  and  one  by  automation.  This 
last  list  of  automation  tasks  will  become  an  additional  requirement  for 
engineering  design. 

The  AOF  hypothesis  should  be  developed  by  an  interdisciplinary  team 
which  includes  both  engineering  and  human  factors  members. 

2.3.3  The  Human  Factors  Hypothesis 

The  human  factors  hypothesis  is  a  proposed  human  organizational  design 
for  one  function.  The  designers  react  to  the  allocation  of  functions  (AOF) 
hypothesis,  and  especially  to  the  list  of  human  control  tasks.  Given  those 
requirements  they  ask  what  human  organization  can  optimally  perform  them. 

The  HF  hypothesis  implies  a  general  plan  including  such  elements  as  an 
organizational  structure,  a  set  of  required  skills,  a  training  plan,  and  a 
set  of  job  aids  or  procedures.  As  the  result  of  this  effort,  the  designers 
may  be  forced  to  reject  or  reconsider  prior  decisions  of  the  design  decision 


The  human  factors  hypothesis  should  be  developed  by  a  HF  design  team 
which  Includes  engineering  members,  and  which  benefits  from  consultation  with 
experienced  users  of  similar  systems. 

2. 3. A  Iteration  and  Feedback 

As  we  have  said,  design  is  characterized  by  cycles  of  hypothesis,  test, 
feedback,  correction,  and  the  progressive  development  of  detail.  These 
feedback  loops  are  most  obvious  at  the  formal  project  level,  but  they  are 
present  at  all  levels  of  design,  including  within  the  design  hypothesis. 

Note  that  each  of  the  three  steps  just  described  can  conclude  with  feedback 
and  reconsideration  of  prior  steps  of  design. 

The  iteration  represented  by  Exhibit  2.3B  includes  a  cyclic  repetition 
of  the  three  included  hypotheses  (engineering,  AOF,  HF)  until  they  are  mutually 
compatible,  and  until  each  of  the  functions  defined  at  step  2.2  has  been  fitted 
with  a  suitable  design  hypothesis.  When  this  has  been  done,  the  effect  is  to 
define  for  the  whole  system  a  hypothetical  engineering  subsystem,  allocation 
of  functions,  and  human  factors  subsystem.  Later  these  steps  will  be  repeated 
to  develop  the  design  at  increasing  levels  of  detail. 


Exhibit  2.3B 
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2.4  TEST  AND  EVALUATION  (T&E) 


This  is  step  2.4  of  the  design  decision  cycle,  as  shown  by  Exhibit  2.4A 
Here  the  designers  evaluate  the  emerging  design,  using  first  deductive  and 
then  empirical  tests.  Tests  are  applied  first  to  single  functions,  and  later 
to  the  integration  of  functions  in  the  system  as  a  whole. 


Exhibit  2.4A 

The  Design  Decision  Cycle  -  Step  2.4 
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2.4.1  Entry  Conditions 


Test  and  evaluation  (T&E)  operates  on  the  hypothetical  elements  of 
design  described  in  Subsection  2.3.  At  first  those  elements  exist  only  in 
functional  design  documents  which  describe  major  functions  and  generalized 
design  solutions.  Later  they  are  described  in  greater  detail,  and  then 
become  highly  specific.  At  that  point  they  may  be  expressed  in  models, 
mockups  or  prototype  equipment ,  and  at  that  point  the  design  might  be 
described  as  "provisional"  rather  than  "hypothetical."  (Refer  to  Exhibit 
2.4B). 

2.4.2  Deductive  Testing 

So  long  as  the  design  exists  only  in  documentation,  it  cannot  be  tested 
empirically,  but  only  by  deduction  and  against  a  priori  criteria.  Deductive 
testing  is  relatively  rapid  and  inexpensive,  and  will  remain  a  major  tool  even 
after  prototype  hardware  has  been  built.  Deductive  tests  are  applied  (1)  to 
each  function  individually  to  test  the  design  hypotheses,  and  (2)  to  the 
system  as  a  whole  to  test  function-to-function  interactions. 

2.4.3  Testing  Single  Functions 

Each  defined  function  must  be  examined,  asking  at  least  the  following 
questions . 

2. 4. 3.1  Does  the  Engineering  Solution  Meet  Criteria?  Is  the  engineering 
solution  suitable?  Is  it  feasible  at  an  acceptable  level  of  technological 
risk?  Is  it  the  best  technology  at  its  cost  level?  Will  calculated 
performance  meet  mission  requirements  within  stated  constraints?  Answers  are 
derived  by  engineering  analysis. 

2. 4. 3. 2  Doe 8  the  Human  Factors  Solution  Meet  Criteria?  Is  the  human  factors 
(HF)  solution  suitable?  Is  It  achievable  within  time  and  human  resource 
constraints?  Is  it  the  best  human  organization  for  the  cost?  Can  it 
exercise  effective  system  control?  Is  it  consistent  with  the  role-of-man 
statement?  Answers  are  provided  by  the  judgment  of  human  factors  engineers. 

2. 4. 3. 3  Are  Engineering  and  Human  Costs  in  Balance?  Is  the  predicted  cost 
of  engineering  balanced  against  human  costs?  They  need  not  be  equal,  but 
should  minimize  total  system  cost  for  the  life  cycle  of  the  system.  Consider 
supporting  hardware  and  human  costs  as  well  as  direct  costs. 

2. 4. 3. 4  Is  the  Allocation  of  Functions  Suitable?  Does  the  allocation  of 
functions  optimize  the  role  of  humans  and  machines  in  performance  of  the 
mission?  See  paragraph  2.4.5,  "Allocation  of  Functions  Test  Criteria." 


2.4.4  Testing  the  System  as  a  Whole 

Next  the  Interaction  of  functions  must  be  tested  for  the  system  as  a 
whole.  Ask  at  least  the  following  questions. 


2. 4. 4.1  Is  the  Engineering  Subsystem  Suitable?  Do  the  engineering  hypotheses 
for  all  functions  taken  together  add  up  to  a  coordinated  engineering  subsystem? 
Are  they  technically  compatible?  Do  functional  inputs  and  outputs  match? 

Is  there  a  consistent  level  of  technology  across  the  system?  Are  costs 
consistent?  Are  development  times  acceptable?  Will  the  engineering  subsystem 
support  all  mission  states?  Answers  are  derived  by  engineering  analysis. 

2. 4. 4. 2  Is  the  Human  Subsystem  Suitable?  Do  the  human  factors  hypotheses  for 
all  functions  add  up  to  a  coordinated  human  factors  subsystem?  Are  they 
organizationally  compatible'-  Are  requirements  for  skill,  ability,  training 
and  experience  reasonably  consistent?  Are  manning  and  training  objectives 
achievable  within  time  and  resource  constraints?  Could  costs  be  reduced  by  a 
different  HF  design?  Will  the  human  organization  support  all  mission  states? 

Is  it  consistent  with  the  role  of  man  statement? 

2. 4. 4. 3  Are  Engineering  and  Human  Costs  in  Balance?  Is  the  expected  cost  of 
humans  in  balance  with  that  of  engineering?  Could  cost  or  performance  be 
improved  by  a  different  balance? 

2. 4. 4. 4  Is  the  Allocation  of  Functions  Optimal?  Does  the  allocation  of 
functions  optimize  the  capabilities  of  people  versus  machines  at  the  whole 
system  level?  The  formal  tests  of  paragraphs  2.4.5  and  2.4.6  will  examine  that 
issue  further. 


2.4.5  Allocation  of  Functions  Test  Criteria 

Four  tests  are  suggested  to  evaluate  allocation  of  functions  (AOF) .  In 
each  of  these  tests,  data  from  the  HEDB  should  be  consulted. 

2. 4. 5.1  Can  the  Human  Subsystem  Meet  Engineering  Performance  Requirements? 

The  first  test  is  whether  each  designated  (or  implied)  job  can  be  performed  to 
criterion  by  a  human.  When  viewed  purely  as  an  engineering  component,  can  a 
human  meet  the  time,  speed,  perception,  processing  and  memory  demands  of  each 
function?  Can  a  human  meet  the  demands  imposed  by  all  functions  to  be 
encountered  in  a  job?  Use  the  human -machine  models  of  Section  5  to  make  these 
judgments. 

2. 4. 5. 2  Can  the  Human  Subsystem  Meet  Human  Performance  Requirements?  This 
test  expands  the  question  of  human  suitability,  to  ask  whether  humans  can 
perform  as  required  considering  their  environmental  needs,  learning  limits, 
physical  characteristics,  reliability,  response  to  stress  and  fatigue, 
psychological  vulnerabilities  and  social  needs.  These  questions  require  the 
judgment  of  a  human  factors  engineer. 

2. 4. 5. 3  Is  Cognitive  Support  Adequate?  This  test  asks  whether  the  human 
decision  maker  will  be  given  sufficient  information  to  meet  decision  require¬ 
ments.  Guidance  for  this  question  is  provided  by  Subsection  4.4,  Affective 
and  Cognitive  Support. 


2. 4. 5. 4  Is  Job  Satisfaction  Optimal?  This  test  examines  factors  which  lead 
to  human  acceptance  of  a  job.  Subsection  4.4  provides  guidance  on  this 
question  also. 


2.4.6  Empirical  Testini 


The  definitive  test  of  a  system  is  actual  performance.  Therefore  we 
seek  such  empirical  tests  as  soon  and  as  often  as  possible.  When  elements  of 
a  system  can  be  modelled,  represented  in  mockups,  or  built  as  prototypes,  we 
test  them  in  simulated  or  real  performance.  Ideally,  this  is  done  in  real 
field  settings  by  typical  human  users. 

As  the  system  develops  there  should  be  an  evolution  toward  greater 
dependence  on  empirical  tests,  but  because  such  tests  are  more  expensive  and 
time  consuming,  they  can  never  replace  deductive  tests,  which  continue  for  the 
life  of  the  system.  Empirical  tests  can  be  used  to  validate  and  calibrate 
deductive  tests,  and  are  the  definitive  measure  of  end  performance. 


2.4.7  Evaluation 


Tests,  whether  deductive  or  empirical,  produce  data  and  not  decisions. 
Test  data  must  be  evaluated,  and  translated  into  analyses  of  what  is  right  or 
wrong  with  the  evolving  design.  Then  decisions  can  be  made  as  to  what  should 
be  done  to  further  improve  the  system. 


2 . 5  ITERATION 

This  is  step  2.5  of  the  design  decision  cycle  as  shown  by  Exhibit  2.5A. 
This  step  produces  a  decision,  based  on  test  data,  as  to  whether  the  design 
hypotheses  meet  criteria,  and  if  not,  what  feedback  treatment  is  required. 

In  this  step  each  function  is  reviewed  for  the  adequacy  of  its  design 
hypothesis,  and  all  functions  are  compared  for  f unction-to-function 
integration.  When  criteria  are  met,  the  design  hypotheses  are  accepted,  and 


Exhibit  2.5A 

The  Design  Decision  Cycle  -  Step  2.5 


they  become  part  of  the  design  at  its  current  level  of  definition.  Functions 
are  then  reviewed  for  their  fineness  of  definition  and  are  fed  back  for 
repartition  until  the  required  level  of  detail  is  achieved.  These  cycles  of 
iteration,  redesign  and  repartition  continue  until  all  functions  meet  criteria 
at  the  required  level  of  detail,  and  the  design  is  complete. 

Block  2.5.1  of  Exhibit  2.5B  represents  the  test  data  at  any  stage  in 
design.  These  data  consist  of  quantified  actual  or  predicted  performance, 
descriptive  data,  and  expert  opinion.  They  may  be  contradictory,  and  often 
are  not  related  tc  any  criterion.  At  this  point  the  design  team  must  decide 
which  functions  should  be  accepted,  and  which  should  be  returned  to  prior 
steps  for  redesign.  This  is  the  point  at  which  it  is  conventional  for  the 
buyers  of  the  system,  and  preferably  the  sponsors  and  end-users,  to  take  part 
in  evaluation.  Hereafter  we  will  refer  to  decisions  as  being  made  by  the 
designers,  with  the  understanding  that  the  buyers  should  participate  as  well. 

Exhibit  2.5B 

Iteration  Of  The  Design  Decision  Cycle 


2.5.1  entry  Conditions 

Step  2.5  operates  on  test  data  from  step  2.4.  These  data  have  been 
incompletely  evaluated  in  that  the  decision  to  accept  or  reject  each  element 
of  design  has  not  been  made.  These  data  include: 

o  Data  on  Individual  Functions.  They  include  data  by  function  on  the 
probable  suitability  of  (1)  the  engineering  hypothesis,  (2)  the 


allocation  of  functions  hypothesis,  and  (3)  the  human  factors 
hypothesis . 


o  Data  on  the  Interaction  of  Functions.  They  include  data  by  sub¬ 
system  or  for  the  system  as  a  whole  on  the  apparent  effectiveness, 
costs  and  future  performance  of  (1)  the  engineering  subsystem,  (2)  the 
human  factors  subsystem,  and  (3)  the  system-wide  allocation  of 
functions . 

2.5.2  Acceptance  by  Function 

Tests  produce  data,  not  decisions.  These  data  must  be  translated  into 
further  actions  within  the  design  decision  logic.  First  the  design  team  looks 
at  the  data  function  by  function,  to  decide  which  functions  require  further 
consideration.  Two  major  considerations  control  this  decision:  system 
requirements,  and  cost  tradeoff  analyses. 

2. 5. 2.1  System  Requirements.  Obviously,  each  function  must  meet  the  system 
requirements  defined  at  step  2.1.  Predicted  performance  must  meet  mission 
performance  requirements,  be  within  constraints,  match  the  engineering  concept 
and  fit  the  role  of  man  definition.  Always  bear  in  mind  that  if  necessary, 
requirements  can  be  renegotiated. 

2. 5. 2. 2  Cost  Tradeoffs.  The  next  question  is  whether  cost  or  effectiveness 
can  be  improved  by  further  design  effort.  Cost  tradeoff  data  developed  during 
the  RDT&E  step  will  apply,  and  the  following  tradeoffs  are  of  particular 
interest : 

o  People  versus  Machines.  Consider  the  expected  balance  between 
equipment  and  people,  for  the  life  cycle  of  the  system.  Allocation  of 
functions  should  maximize  effectiveness  by  allocating  functions  to 
whichever  means  will  perform  best,  and  minimize  costs  by  the  same 
decisions . 

o  Costs  of  Design.  A  final  consideration  is  the  costs  of  the  design 
effort  itself.  In  general,  a  design  hypothesis  should  continue  to  be 
reconsidered  so  long  as  the  costs  of  further  design  effort  are 
justified.  Many  cycles  of  effort  should  lead  to  better  design,  and  to 
a  reduced  number  of  design  errors.  It  is  cheaper  to  correct  design 
errors  on  paper  than  by  retrofitting  hardware.  On  the  other  hand, 
design  itself  costs  money  and  cannot  continue  indefinitely.  This 
usually  is  an  academic  issue,  since  the  schedule  never  provides  all 
the  time  the  designers  need. 


2.5.3  Integration  of  Functions 

Once  hypotheses  are  acceptable  function  by  function,  they  must  be 
examined  as  a  whole.  At  this  point  the  collective  cost  and  effectiveness  of 
the  engineering  and  human  subsystems  are  taken  into  account.  Again  the  major 
considerations  are  system  requirements  and  cost  tradeoffs.  The  predicted 
collective  performance  of  each  subsystem  is  compared  to  requirements,  and 
cost  tradeoff  data  are  examined.  Elements  of  the  design  which  can  benefit 


from  further  reconsideration  are  returned  to  that  step  in  design  which  seems 
to  have  been  deficient.  Here  the  problem  is  to  realistically  assess  the 
interaction  of  functions  across  the  system. 

This  assessment  can  be  simplified  by  comparing  three  or  four  functions 
at  a  time.  The  designers  compare  (and  may  use  mathematical  models)  those 
functions  which  are  critically  active  during  each  single  system  state  or 
transition,  and  when  an  unacceptable  integration  of  functions  is  detected, 
return  those  functions  which  are  at  fault  for  redesign. 

2.5.4  Accepted  Elements  of  Design 

Any  function  which  meets  criteria  at  blocks  2.5.2  and  2.5.3  becomes  an 
accepted  element  of  design  (block  2.5.4).  These  elements  do  not  constitute  a 
complete  design,  since  some  functions  were  returned  for  redesign  and  are 
missing,  and  most  functions  are  not  yet  decomposed  to  the  required  level  of 
detail . 


2.5.5  Fineness  of  Definition 


Before  functions  are  repartitioned,  they  are  ordinarily  allowed  to 
accumulate  as  accepted  elements  of  design  (block  2.5.4)  until  those  elements 
represent  a  reasonably  complete  design  at  a  given  level  of  detail.  Such 
functional  levels  may  correspond  to  standard  phases  of  design,  such  as  "system 
definition,"  "preliminary  design,"  or  "prototype  development."  More  frequently, 
several  levels  of  partitioning  occur  between  formal  phase  points.  In  any  case 
functions  are  periodically  returned  to  step  2.2  for  further  decomposition 
(block  2.5.5).  The  fineness  of  definition  required  varies,  but  must  be 
sufficient  to  permit  the  identification  of  specific  system  components  and 
specific  human  tasks. 


2.5,6  Determine  Feedback  Treatment 


When  a  function  must  be  reconsidered  it  may  be  routed  uo  any  prior 
step  of  design,  depending  on  the  defects  of  the  function.  Most  frequently  the 
identified  defect  is  in  the  engineering  or  human  factors  hypothesis,  and 
the  function  is  returned  to  the  appropriate  substep  of  step  2.3,  the  design 
hypothesis.  In  other  cases  a  function  may  be  too  broad  to  permit  a  good 
single  solution,  or  a  better  solution  may  be  achievable  if  the  boundary 
between  two  functions  is  redrawn.  Such  functions,  and  those  returned  for 
repartition,  are  returned  to  step  2.2  for  redefinition.  Finally,  cases  occur 
in  which  the  design  criteria  are  too  restrictive,  and  such  functions  may 
require  a  renegotiation  of  requirements  at  step  2.1. 


2.5.7  Completion  of  Design 

When  a  function  has  been  partitioned  to  the  level  required  and  meets 
criteria  it  becomes  an  element  of  the  final  design.  When  all  functions  have 
passed  that  test  the  design  is  complete. 
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Some  texts  consider  "functional  design"  to  be  complete  when  a  set  of 
functions  is  defined  but  before  any  physical  components  have  been  selected. 
It  is  useful  to  have  such  a  "functional  design"  phase,  and  to  defer  concrete 
hardware  decisions  as  long  as  possible  to  keep  the  options  open.  But  in 
practice  the  iterative  process  of  defining  functions,  developing  hypotheses 
and  testing  must  continue  throughout  the  design  process.  Even  then  it  does 
not  stop.  It  continues  throughout  the  operating  life  of  the  system,  and 
contributes  to  the  processes  of  evaluation,  modification,  redesign  and 
disposal.  The  design  decision  cycle  continues  so  long  as  any  element  of  the 
system  may  be  subject  to  change  or  evolution. 


SECTION  3 


STEPS  IN  THE  DESIGN  HYPOTHESIS 


This  section  expands  upon  Subsection  2.3,  The  Design  Hypothesis.  That 
hypothesis  is  the  heart  of  design  logic  and  contains  many  actions  critical  to 
the  allocation  of  functions  (AOF) .  Therefore  we  will  describe  it  in  procedural 
detail.  To  summarize  Subsection  2.3,  the  design  hypothesis  consists  of  three 
included  hypotheses,  (1)  an  engineering  hypothesis,  (2)  an  AOF  hypothesis,  and 
(3)  a  human  factors  hypothesis  (Exhibit  3).  They  are  normally  made  in  that 
order.  They  may  occur  as  part  of  the  designer's  unconscious  thinking  processes 
or  formally  in  a  design  procedure,  but  the  elements  of  the  AOF  decision  are 
embedded  in  those  hypotheses,  as  we  will  see.  Before  proceeding,  it  will  be 
useful  to  examine  some  characteristics  of  the  design  hypothesis. 


Exhibit  3 

Steps  In  The  Design  Hypothesis 
(Derived  from  Exhibit  I) 


How  to  Approach  the  Design  Hypothesis 

The  design  hypothesis  is  the  inductive  step  in  systems  development,  and 
it  is  not  achieved  by  deductive  logic.  There  is  no  rule  or  formula.  We  tend 
to  regard  engineering  and  system  development  as  exact  sciences.  We  may 
therefore  expect  design  to  be  achieved  *  nathematical  or  systematic 
procedures.  But  hypothesis  is  the  inventive  step  of  design,  a  step  which 
depends  on  creative  logic,  exploration  and  judgment,  rather  than  on  method  or 
algorithm.  In  fact,  the  development  of  a  design  hypothesis  is  characterized 
by  the  following  conditions : 

o  Not  all  variables  are  identified. 


o  Many  identified  variables  cannot  be  measured, 
o  Most  decisions  are  value  laden. 

o  Most  decisions  include  a  statistical  estimate  of  risk. 

o  All  options  are  open,  including  some  options  which  must  be 
discovered. 

o  The  human  element  is  particularly  hard  to  foresee. 

o  Even  engineering  predictions  depend  on  expert  opinion. 

Professional  Judgment  .  Under  these  conditions  we  depend  ultimately  on  the 
judgment  of  informed  professionals.  At  each  step  in  the  process  we  can  find 
some  limited  quantitative  information.  This  may  include  data  on  expected 
engineering  performance  and  on  the  control  demands  which  a  hypothesis  will 
impose,  but  these  data  are  speculative,  since  the  new  system  does  not  yet 
exist.  We  can  predict  human  performance  only  by  analogy  to  past  experience. 
What  firm  data  we  have  must  be  evaluated  against  the  variables  and  unknowns, 
using  expert  judgment.  There  are  proven  ways  to  proceed,  which  include  the 
following: 

Use  a  Panel .  Professional  judgment  will  be  most  effective  if  it  is  a 
consensus  and  represents  several  disciplines.  Such  judgments  can  be  made  by 
a  panel  procedure,  which  should  have  the  following  features:  (1)  Documents 
and  resources  should  be  assembled  beforehand.  (2)  Professional  qualifications 
should  include  a  senior  member  with  broad  systems  experience,  human  factors  or 
equivalent  members,  and  design  engineers  from  each  specialty  concerned. 

(3)  Meetings  should  be  formal  and  controlled  by  an  agenda.  (4)  Records 
should  be  kept  of  alternatives  considered,  decisions  made,  and  the  rationale 
for  decision.  (5)  A  forced  decision  strategy  should  be  employed  to  speed 
design. 

Analogy  to  Known  Systems.  A  useful  source  of  information  will  be  experience 
from  older  analogous  systems.  In  fact,  this  is  the  source  of  all  design  data, 
predictive  or  speculative.  Analogous  systems  are  particularly  useful  when 
there  are  records  or  anecdotal  data  about  human  performance  in  those  systems; 
unfortunately  such  data  are  seldom  preserved.  This  leaves  only  the  personal 
experience  which  members  of  the  team  may  have  had  with  such  systems. 

User  Experience.  Possibly  the  single  most  useful  source  of  information  is  the 
experience  of  users .  Experienced  operators ,  commanders ,  pilots  and  mid-level 
decision  makers  should  be  present  on  the  design  team,  or  available  for 
consultation. 

Forced  Decisions .  A  panel  will  be  cumbersome  if  required  to  actually  agree  on 
each  point.  Several  hundred  separate  decisions  must  be  made  during  each  of 
many  design  cycles.  It  is  more  useful  to  make  those  decisions  quickly  and 
test  them  repeatedly  than  to  seek  perfection  the  first  time.  An  authoritarian 
procedure  is  suggested,  in  which  discussion  is  followed  by  a  brief  effort  to 
reach  consensus,  but  concluded  if  necessary  by  a  leader's  prescribed  decision. 


The  considerations  just  listed  should  be  kept  in  mind,  while  formulating 
design  hypotheses  using  the  three  step  procedure  which  follows. 

3.1  THE  ENGINEERING  HYPOTHESIS 

An  engineering  hypothesis  is  the  first  step  in  design  hypothesis,  and 
logically  precedes  other  hypotheses.  Subsequent  steps  react  to  that  hypo¬ 
thesis,  since  it  predetermines  that  certain  roles  will  be  performed  by 
machines.  By  this  hypothesis  the  designers  propose  an  engineering  solution  - 
a  potentially  optimum  engineering  means  of  meeting  mission  requirements  for 
one  function.  This  hypothesis  is  stated  in  functional  terms. 


Exhibit  3.1  A 

The  Engineering  Hypothesis 
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3.1.1  Treat  One  Function  at  a  Time 

Functions  identified  earlier  at  step  2.2  constitute  a  provisional  list 
of  functions.  At  first  this  list  contains  a  few  major  functions;  later  it 
will  contain  many  functions  narrowly  defined  (see  Exhibit  3.1A,  block  3.1.1). 
Select  functions  from  this  list  one  at  a  time.  Normally,  choose  them  in  the 
order  of  their  Importance,  mission-critical  functions  first,  then  non-critical 
and  support  functions.  If  there  are  functions  which  are  time-  or  technology- 
critical  to  design  -  those  which  may  be  technically  difficult  to  achieve  or 
which  lie  on  the  project  critical  path  -  consider  them  critical  even  if  they 
are  support  functions. 


Use  an  engineering  team  to  form  this  hypothesis.  This  does  not  mean 


that  it  can  be  based  on  narrow  engineering  criteria.  Since  this  hypothesis 
constrains  the  subsequent  AOF  and  human  factors  hypotheses,  it  must  be  made 
intelligently  and  with  multidisciplinary  consultation.  In  particular, 
consider  the  following: 

o  Human  Factors.  Consider  the  needs  of  users  and  maintainers,  and  the 
costs  of  humans  in  the  system.  Use  human  factors  consultants.  Consult 
operators  and  maintenance  personnel. 

o  Other  Functions.  Although  only  one  function  can  be  considered  at  a 
time,  remember  that  all  will  eventually  be  integrated  into  one  system. 
Consider,  to  the  extent  feasible,  the  probable  requirements  of  other 
functions,  especially  those  which  have  already  been  defined. 


3.1.2  State  Alternate  Engineering  Concepts 

Identify  the  alternative  engineering  means  by  which  a  defined  function 
might  be  accomplished  (see  Exhibit  3.1A,  block  3.1.2).  Typically  these  are 
known  technologies  which  can  be  applied  ,:off  the  shelf"  or  with  modifications 
Less  frequently  they  are  new  inventions ,  based  on  analogous  technology  but 
with  new  qualitative  capabilities.  Occasionally  they  may  provide  a  totally 
new  technology  by  exploiting  theory  or  research. 

This  step  is  the  heart  of  the  engineering  hypothesis  and  the  point  at 
which  creative  development  or  invention  takes  place;  a  permissive  criterion 
must  apply.  Concepts  should  be  considered  even  though  they  may  be  vulnerable 
to  criticism  or  appear  unlikely  choices.  Consider  as  one  alternative  perform 
ance  of  a  function  by  humans  alone  -  one  engineering  option  is  not  to  use 
machinery . 

State  engineering  alternatives,  when  possible,  in  functional  terms. 
Keep  the  design  options  open  even  if  an  off-the-shelf  technology  seems  the 
obvious  choice. 


3.1.3  Select  an  Eneineerine  Hypothesis 


Now  select  one  engineering  concept  as  a  working  hypothesis  (Exhibit 
3.1A,  block  3.1.3).  Choose  a  solution  which,  based  on  preliminary  analysis, 
seems  most  likely  to  meet  engineering  criteria,  and  consider  the  probable 
impact  of  the  selection  upon  other  elements  of  the  emerging  design.  To  the 
extent  that  information  is  available,  estimate  the  impact  on  the  human 
subsystem  design,  interaction  with  other  functions,  life-cycle  modifiability, 
and  other  system  variables  which  may  apply.  Because  these  are  numerous  and 
mostly  unquantifiable,  this  will  be  by  a  consensus  of  expert  opinion.  As 
always,  describe  the  selected  hypothesis  in  functional  terms.  Name  a  range 
of  hypothesized  technologies,  or  state  the  solution  in  input-output  terms. 
Preserve  the  list  of  alternatives  not  selected,  and  record  the  decision 
rationale;  these  data  may  be  useful  if  the  engineering  hypothesis  must  be 
reconsidered. 


3.1.4  Identify  the  Elements  of  the  Hypothesis 


Now  that  an  engineering  hypothesis  has  been  selected,  identify  the 
products  of  that  decision.  These  will  be  needed  to  support  other  decisions 
which  follow.  At  least  four  products  are  important,  and  are  shown  by  four 
document  symbols  on  Exhibit  3.1A. 

3. 1.4.1  The  Hardware  Concept.  This  is  the  implied  hardware  requirement, 
expressed  in  functional  or  performance  terms. 

3. 1.4. 2  The  Software  Concept.  This  is  the  implied  software  requirement, 
expressed  in  functional  or  performance  terms. 

3. 1.4. 3  System  States  and  Transitions.  Earlier,  in  step  2.2,  the  future 
system  was  first  described  in  terms  of  system  states  and  transitions  between 
those  states.  Now  that  provisional  hardware  and  software  concepts  have  been 
proposed,  it  is  possible  to  describe  actual  engineering  states  and  transitions. 
These  should  now  be  identified  and  listed.  They  can  be  shown  as  a  state  and 
transition  diagram  like  that  of  Exhibit  3. IB. 


Exhibit  3. IB 

Top-Level  State  And  Transition  Diagram 
For  Air-Ground  System 


The  major  at  at  as  whicn  the  syitem  may  be  required  to  aeaume  during  its  life  cycle  are 
diagrammed  and  are  connected  by  arrows  representing  the  expected  normal  and  emergency 
transitions  between  states. 


3. 1.4. 4  Control/Display  Requirements.  System  states  imply  control  require¬ 
ments  to  maintain  their  stability,  and  to  govern  transitions  from  state  to 
state.  Now  use  the  state  and  transition  diagram  to  Identify  requirements  for 
controls.  Use  the  control  requirements  to  identify  requirements  for  instru¬ 
mentation  and  data  display.  As  always,  state  these  in  functional  terms  so 
far  as  is  possible. 
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3. 1.4. 5  Feedback.  At  any  time  it  may  be  recognized  that  an  optimal  engineer¬ 
ing  hypothesis  is  not  achievable  for  the  function  as  defined,  or  under  defined 
constraints.  When  this  happens,  feedback  to  prior  steps  is  appropriate 
(not  shown  on  Exhibit  3.1A) . 


3.1.5  Documentation 


Document  key  decisions  made  during  formation  of  the  engineering 
hypothesis.  Record  the  alternative  engineering  concepts,  the  selected 
hypothesis,  and  rationale  for  selection.  Record  the  decision  products,  and 
enter  these  data  in  the  design  data  base  (see  Exhibit  3.1A,  block  3.1.5). 


3.2  THE  ALLOCATION  HYPOTHESIS 

Once  an  engineering  hypothesis  is  proposed  it  must  be  fitted  into  a 
system  which  includes  people.  This  step  makes  a  provisional  assignment  of 
roles  and  tasks  to  people  or  machines,  and  in  so  doing  defines  the  boundary 
between  the  human  and  machine  subsystems,  sometimes  called  the  "human-machine 
interface. " 


Exhibit  3.2A 

Allocation  Of  Functions  Hypothesis 
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The  allocation  hypothesis  is  made  in  part  by  a  decision  to  accept  or 
reject  an  allocation  implied  by  the  engineering  hypothesis,  and  then  by 
decisions  to  allocate  those  roles  and  tasks  which  are  not  yet  determined.  In 
particular,  control  tasks  must  be  allocated  to  humans  or  automation.  These 
decisions  use  decision  criteria  to  be  described  later  in  Section  4.  Early  in 
design  an  entire  function  will  rarely  be  allocated  wholly  to  humans  or  to 
machines.  Instead,  since  functions  are  broadly  defined,  they  will  usually  be 
shared  between  the  two.  As  design  progresses  and  as  functions  become  smaller 
and  more  specific,  some  of  them  will  be  allocated  exclusively  to  humans  or 
to  machines.  Finally,  at  the  completion  of  design  all  functions  will  be 
defined  at  their  finest  level,  and  all  will  be  allocated  exclusively  to  humans 
or  to  machines  and  automation. 

The  allocation  of  functions  hypothesis  is  formulated  by  an  inter¬ 
disciplinary  team  which  includes  both  human  factors  and  engineering  members. 
The  procedure  is  as  follows,  and  as  illustrated  by  Exhibit  3.2A. 

3.2.1  Entry  Conditions 

Allocation  of  functions  acts  on  the  four  products  of  the  previous  step: 
the  hardware  concept,  the  software  concept,  the  table  of  states  and  tran¬ 
sitions,  and  the  list  of  control  and  display  requirements.  The  first  three 
describe  the  engineering  solution,  and  the  last  describes  tasks  which  must  be 
allocated . 

3.2.2  Identify  the  Implied  Allocation  of  Roles  and  Tasks 


The  engineering  solution  implies  that  certain  roles  or  tasks  will  be 
performed  by  machine.  The  term  "tasks"  designates  actions  which  must  be  taken 
by  people  or  machines,  actions  which  can  be  described  by  a  verb-object  phrase 
such  as  "adjust  elevator  trim."  The  term  "roles"  designates  more  generalized 
actions  or  sets  of  tasks,  sometimes  not  yet  fully  understood,  actions  which 
can  be  described  by  a  more  general  phrase  such  as  "maintain  stability  in 
flight."  Thus  the  term  "roles"  applies  to  the  description  of  human  or  machine 
actions  early  in  system  design  when  tasks  are  as  yet  undefined,  and  "tasks" 
describes  the  highly  specific  apportionment  of  actions  which  the  final  system 
design  must  include. 

Identify  those  roles  or  tasks  for  whicn  an  allocation  is  predetermined 
by  the  engineering  hypothesis,  and  those  which  remain  open  to  choice.  Classify 
them  into  three  categories : 

°  Performed  by  Machine.  Those  which,  by  implication  of  the  engineer¬ 
ing  hypothesis,  must  be  performed  by  machines. 

°  Performed  by  Humans .  Those  which,  by  implication,  must  be  performed 

by  humans. 

°  Open  to  Choice.  Those  which  remain  to  be  allocated. 

This  step  results  in  a  statement  of  how  humans  and  machines  will  act 
together  to  perform  and  control  a  function.  Later  in  design  that  statement 
may  describe  functions  performed  exclusively  by  humans  or  by  machines. 


3.2.3  Determine  Acceptability  of  the  Engineering  Hypothesis 


Block  3.2.3  of  Exhibit  3.2A  is  the  point  at  which  the  designers  accept 
or  reject  the  engineering  hypothesis.  Examine  that  hypothesis  and  decide 
whether  it  will  unduly  restrict  future  design  decisions,  and  whether  it  is 
likely  to  lead  to  an  optimal  end  design.  This  decision  is  made  using  expert 
judgment,  and  by  applying  the  criteria  of  Section  4.  In  addition,  ask  the 
following  questions: 

3.2.3. 1  Acceptability  of  the  Role  of  Man.  Are  the  roles  (or  tasks)  which 
humans  will  perform  acceptable? 

o  Do  humans  retain  essential  control  functions?  Can  they  start  or 
stop  key  processes,  insert  command  and  policy  decisions,  and  intervene 
in  emergencies? 

o  Will  humans  be  adequately  informed?  Can  they  understand  what  the 
system,  particularly  its  remote  and  automatic  processes,  is  doing? 

o  Are  tasks  assigned  to  humans  within  the  limits  of  human  ability? 

Can  humans  reliably  perform  as  required? 

o  Are  the  conditions  under  which  humans  are  used  psychologically 
suitable?  Will  humans  be  comfortable  and  satisfied  to  perform  as 
required? 

3. 2.3.2  Feasibility  of  a  Human  Factors  Solution.  Is  a  human  organization  to 
support  this  function  feasible? 

o  Will  people  with  suitable  abilities,  skills,  and  knowledge  be 
available?  Can  they  be  recruited,  selected  and  employed? 

o  Is  the  required  training  feasible  and  affordable? 

o  Is  a  suitable  job,  crew  and  management  structure  achievable? 

o  Is  a  satisfactory  career  structure  achievable? 

3. 2. 3. 3  Cost/Value.  Will  the  emerging  allocation  of  roles  and  tasks  be 
appropriately  balanced  for  cost  and  value? 

o  Would  a  different  engineering  hypothesis  permit  a  better  balance 
between  humans  and  technology?  (Formal  cost/value  analysis  comes 
later  -  now  make  a  best  estimate  for  one  function.) 

If  the  answer  to  any  of  these  questions  is  "no,"  the  engineering  hypothesis 
may  constrain  design  too  severely.  Go  back  to  prior  steps  of  the  design 
logic,  and  reformulate  the  engineering  hypothesis. 


3.2.4  Allocate  Open-to-Choice  Roles  and  Tasks 

Allocate  those  roles  and  tasks  which  are  not  predetermined,  using  the 
criteria  of  Section  4. 


3.2.5  Allocate  Control/Display  Requirements 

One  input  remains  to  be  treated.  The  list  of  control  and  display 
requirements  implies  a  set  of  control  and  display  roles  (or  tasks) ,  the 
allocation  of  which  is  open  to  choice  between  humans  and  automation.  Allocate 
those  roles  and  tasks  so  as  to  secure  optimal  control  performance.  Use  the 
criteria  of  Section  4. 


3.2.6  Output  Products 

The  AOF  hypothesis  is  expressed  by  the  three  decision  products  shown  as 
document  symbols  on  the  right  of  Exhibit  2.2k.  They  are: 

3. 2. 6.1  Machine  Roles  and  Tasks.  This  is  a  list  of  roles  and  tasks  which 
are  provisionally  assigned  to  machines.  Included  are  (1)  roles/tasks  which 
were  predetermined  by  the  engineering  hypothesis  and  (2)  those  allocated  by 
the  designers. 

3. 2. 6. 2  Human  Roles  and  Tasks.  This  is  a  list  of  roles/tasks  provisionally 
assigned  to  humans,  It  includes  (1)  those  predetermined  by  the  engineering 
hypothesis,  (2)  those  allocated  by  the  designers,  and  (3)  control  tasks 
allocated  to  humans. 

3. 2. 6. 3  Automation  Task  Requirements.  This  is  a  list  of  requirements  for 
automatic  control  functions,  which  becomes  a  requirement  for  additional 
engineering  development.  These  data  will  be  fed  back  to  the  engineering 
hypothesis  step,  as  newly  identified  functions. 


3.2.7  What  Does  an  Allocation  of  Functions  Look  Like? 


At  this  point  we  might  ask  what  an  allocation  of  functions  looks  like. 
The  answer  is  that  it  differs  as  the  design  develops.  Two  things  change: 

(1)  As  functions  are  partitioned  to  increasing  levels  of  detail,  the  number 
of  functions  increases,  and  each  function  represents  a  smaller  proportion  of 
the  whole  system.  (2)  The  allocation  progresses  from  a  set  of  generalized 
lists  of  human/machine  roles,  toward  specific  statements  at  the  component 
level.  Exhibit  3.2B  illustrates  an  AOF  document,  and  represents  a  nuclear 
power  plant  control  room  design  after  about  four  levels  of  partitioning.  Such 
a  document  must  include  at  least  six  kinds  of  information,  as  follows: 

3. 2. 7.1  Identity  of  the  Function.  Field  1  of  Exhibit  3.2B  identifies  a 
function.  The  code  1.5. 2. 3  in  that  field  identifies  the  address  of  that 
function  in  design  documentation,  and  suggests  that  it  is  number  3  among  the 
subfunctions  of  the  larger  function  1.5.2.  The  descriptive  name  of  the 
function  follows.  This  function  supplies  filtered  air  to  the  reactor 
auxiliary  building  (RAB) . 


3. 2. 7. 2  Identity  of  Equipment  Subsystems.  Field  2  identifies  the  principal 
subsystem  concerned  Cheating,  ventilating  &  air  conditioning),  and  those 
systems  with  which  it  interacts. 


Exhibit  3.2B 

Contents  Of  An  Allocation  Of  Functions  Document 


1  Function 

Code  15  2  3  Heat,  cool,  vent  areas  of  RAB  with  filtered  air  at  specified  temperatures  Maintain  human  habitability. 
Cool  RAB  equipment  Control  radiation  leakage 

2  Subsystems 

HVAC  RAB  subsystem  RAB  equipment  On/off  site  power  Pumped  river  cooling  water  system  Ambient  air  Heating 
steam  supply  system 

3  System  States  & 

(1 )  Normal  operation 

(2)  Equipment  fire  (3)  Equipment  radiation  leak  (4)  Radiation  leak  external  to  RAB  (6)  HVAC 

Transitions 

component  failure/mamtenance  (7)  Transition  to/from  (2)  (3)  (4)  (5)  (6) 

4  Control  Requirements 

5  Machine  Roles 

6  Human  Roles 

Maintain  normal  cooling  level 

Activate  fans,  refrigeration,  heating  coils. 

Recognize  abnormality 

Maintain  normal  heat  level 

using  setpoint  thermostats 

Set  thermostats  seasonally  by  phone  to  plant 

Maintain  required  rate  of  air  flow 

Display  temperature  and  flow  data 

Equipment  operator 

• 

Display  predicted  data  from  trend  forecasts. 

Make  periodic  log  entries  per  procedure 

• 

Provide  abnormal  parameter  alarms 

Start  emergency  fans 

Etc 

Provide  equipment  failure  alarms 

• 

• 

Control  dampers  (normal)  using  program  logic 

e 

Start  backup  fans 

e 

• 

Filter  radiation  from  exhaust  air 

• 

e 

Reconfigure  dampers  for  radiation 

• 

Reconfigure  dampers  to  contain  radiation 

conramment 

• 

• 

• 

Reconfigure  dampers  to  control  fire 

e 

• 

Etc 

Etc 

• 

Etc 

3. 2. 7. 3  System  States  and  Transitions.  Field  3  lists  the  system  states  and 
transitions  which  must  be  controlled. 

3. 2. 7. A  Control  Requirements.  Field  4  lists  the  control  requirements  which 
the  states  and  transitions  are  considered  to  imply. 

3. 2. 7. 5  Machine  and  Human  Roles.  Fields  5  and  6  list  roles  (or  tasks)  which 
are  assigned  to  humans  and  machines.  These  correspond  (on  this  form)  to 
identified  control  requirements.  When  a  control  requirement  is  allocated 
wholly  to  automation,  an  entry  appears  only  in  column  5,  and  when  allocated 
to  humans,  only  in  column  6.  For  instance  "reconfigure  dampers  for  radiation 
containment"  is  allocated  to  humans  and  is  reflected  by  the  entry  shown. 

When,  however,  a  role  is  still  defined  at  a  general  level  and  stated 
broadly,  as  they  are  here  at  the  4th  level  of  indenture,  many  will  be 
performed  by  some  combination  of  equipment  and  humans.  In  these  cases  there 
are  entries  in  both  columns  5  and  6,  as  is  the  case  for  the  first  three 
control  requirements  shown. 

Of  course,  as  the  design  approaches  completion,  this  form  will  show  only 
specific  tasks,  and  they  will  be  allocated  specifically  to  humans  or  to 
automation.  Control  requirements  will  be  specific  actions  such  as  "adjust  no. 
16  fan  speed,"  and  an  action  will  appear  in  one  column  only,  such  as  "adjust  to 
standard  6600  RPM  using  a  digital  speed  control". 


3.3  THE  HUMAN  FACTORS  HYPOTHESIS 


The  third  and  final  step  in  design  hypothesis  is  to  form  a  human 
factors  (HF)  hypothesis.  This  step  comes  last,  since  it  reacts  to  require¬ 
ments  and  constraints  determined  by  the  prior  two  hypotheses.  By  forming  this 
hypothesis  the  designers  specify  a  provisional  human  organization  to  perform 
the  roles  assigned  to  humans  by  one  function.  Take  steps  as  follows: 


3.3.1  Detail  Role/Task  Requirements 

Principal  input  to  the  HF  hypothesis  is  the  list  of  human  roles  and 
tasks  from  step  3.2.  This  list  is  incomplete,  since  it  is  derived  from 
operations  and  reflects  operating  requirements  only.  Now  add  requirements 
for  communications,  intelligence,  maintenance,  support,  logistics  and  system 
acquisition.  These  must  be  estimated  from  the  existing  list  of  roles  and 
tasks.  Develop  and  list  the  four  kinds  of  role/task  data  shown  as  stacked 
document  symbols  on  Exhibit  3.3. 


Exhibit  3.3 

The  Human  Factors  Hypothesis 


3 

3 -3. 1.1  C  1  Roles/Tasks.  People  are  required  to  command,  supervise,  control, 
conxnunicate ,  and  provide  information  needed  to  govern  and  exploit  the  function. 

3. 3. 1.2  Acquisition  Roles/Tasks.  People  are  needed  to  acquire  the  system, 
both  hardware  and  human  elements.  They  will  be  needed  for  the  life  of  the 


system  to  conduct  acquisition,  test,  modification,  redesign  and  disposal. 
These  can  include  personnel  of  the  sponsor  or  user  staff,  as  well  as  those 
within  the  system. 


3. 3. 1.3  Operating  Roles/Tasks.  Operating  personnel  include  those  who  pilot, 
control  and  operate  the  system,  both  its  prime  mission  elements  and  support 
structures . 

3. 3. 1.4  Maintenance  Roles/Tasks.  People  are  required  to  maintain  the 
mission  and  support  hardware,  and  to  maintain  the  human  organization.  On- 
the-job  training,  for  instance,  is  a  HF  maintenance  activity. 


3.3.2  Combine  with  Other  Roles  and  Tasks 


Combine  these  role/task  data  with  role/task  data  developed  earlier  for 
other  functions.  These  data  are  accumulating  in  the  design  data  base.  To 
forecast  human  requirements  we  look  not  just  at  one  function  at  a  time,  but 
at  the  sum  of  role/task  requirements,  recognizing  that  people  rarely  support 
only  one  function  at  a  time.  Combine  and  compare  human  requirements  of  the 
function  under  design  with  those  for  all  functions  previously  defined. 
Collectively  these  data  become  the  whole  system  human  requirements  represented 
by  a  document  symbol  in  the  top  line  of  Exhibit  3.3. 


3.3.3  Forecast  Life  Cycle  Human  Requirements 

To  be  useful,  role/task  data  need  to  be  expressed  in  terms  of  people 
by  category  and  availability  dates.  Estimate  human  performance  requirements 
for  the  system  life  cycle.  State  numbers  of  people  required  by  date  and 
category.  Express  time  in  terms  of  development  and  system  schedule  mile¬ 
stones.  Express  humans  in  terms  of  ability,  skill,  knowledge  and  experience. 


3.3.4  Human  Factors  Development  Plan 

Hypothesize  a  human  factors  development  plan.  This  is  a  plan  for  the 
acquisition  and  life-cycle  management  of  the  human  subsystem,  expressed  in 
functional  terms.  At  each  stage  of  system  development  this  plan  represents 
the  developer's  hypothesis  concerning  the  human  organization  for  the  system  as 
a  whole.  Include  elements  such  as: 

o  An  organizational  structure  and  management  plan. 

o  Personnel  selection  criteria  for  ability,  skill,  knowledge  and 

experience . 

o  Plans  for  recruitment,  selection,  and  relocation. 

o  Training  plans. 

o  Job  design,  job  progression  plan,  crew  structures. 


o  Operator  aids,  job  procedures,  maintenance  documentation. 


3.3.5  Is  the  Design  Hypothesis  Complete? 

The  final  step  in  design  hypothesis  is  to  test  its  completion  (block 
3.3.5  of  Exhibit  3.3).  Ask  the  following  questions: 

3. 3.5.1  Was  a  Suitable  HF  Hypothesis  Achieved?  Sometimes  a  good  HF  hypothesis 
cannot  be  found.  Sometimes  there  is  no  discernible  organization  which  can 
perform  the  required  roles  and  tasks.  If  this  is  the  case,  feed  the  function 
back  to  a  prior  step  of  design  to  change  the  requirements,  the  function,  the 
engineering  hypothesis,  or  the  AOF  hypothesis. 

3. 3. 5. 2  Is  the  HF  Hypothesis  Efficient?  Does  the  HF  hypothesis  impose  an 
inefficient  human  organization?  Does  it  make  effective  use  of  resources  in 
the  HF  development  plan?  Does  it  impose  unneeded  complexity  (such  as  special 
training)?  If  it  is  inefficient,  feed  the  function  back  for  appropriate 
redesign. 


3. 3. 5. 3  Does  the  Design  Hypothesis  Meet  Human  Factors  Criteria?  This  is  the 
most  critical  test,  and  it  applies  to  the  design  hypothesis  as  a  whole,  rather 
than  just  the  HF  hypothesis.  Ask  the  following  four  questions: 

o  Can  humans  provide  the  technical  elements  of  performance?  Use  the 
models  of  Section  5,  and  consider  the  human  operator  as  if  he/she  were  a 
machine  component.  Partition  human-machine  transactions  into  the  sequential 
steps  of  perceptual,  cognitive,  physiological  and  machine  performance  which 
they  include.  Determine  whether  humans  will  be  able  to  perform  each  of  those 
elements  as  required. 

o  Can  humans  provide  the  behavioral  elements  of  performance?  Human 
performance  is  affected  by  behavioral,  social  and  psychological  circumstances. 
Determine  whether  humans  will  be  able  to  perform  as  elements  of  the  organiza¬ 
tional  and  social  setting  which  the  design  hypothesis  implies. 

o  Is  the  HF  support  structure  adequate?  Examine  the  proposed  human 
factors  development  plan.  Question  the  adequacy  of  the  proposed  training, 
procedures,  selection  and  organizational  structure.  Will  they  support  people 
in  performance  of  the  function  as  required? 

o  Is  cognitive  support  adequate?  Refer  to  Subsection  4.4,  and  examine 
the  proposed  control,  display  and  intelligence  provisions.  Determine  whether 
they  will  meet  human  needs  for  information. 

3. 3. 5. 4  Are  the  Three  Design  Hypotheses  Mutually  Optimal?  A  final  question 
concerns  whether  the  engineering,  AOF  and  HF  hypotheses  are  mutually  optimal. 
Ask  these  four  questions: 

o  Do  they  meet  all  requirements?  Check  to  be  certain  that  all  roles 


o  Do  hypotheses  work  together?  Check  again  to  ensure  that  the  three 
hypotheses  are  mutually  compatible  and  will  work  together. 

o  Is  their  cost/value  effective?  Check  whether  the  engineering 
hypothesis  implies  an  excessive  cost  for  equipment  or  development.  Check 
whether  the  HF  hypothesis  will  require  humans  to  perform  tasks  better 
performed  by  machines. 

o  Is  the  design  hypothesis  consistent  with  other  hypotheses?  Finally, 
ask  concerning  the  design  hypothesis  as  a  whole  -  is  it  reasonably  consistent 
with  other,  previously  defined  hypotheses  in  form,  cost,  level  of  technology 
and  human/machine  balance?  All  functions  should  exercise  a  reasonably 
consistent  level  of  technology  unless  there  is  a  clear  reason  for  variation. 
The  role  of  man  should  be  consistent.  Engineering  hypotheses  should 
exercise  a  coherent  group  of  technologies  -  not,  for  instance,  unnecessarily 
mixing  electrical  and  hydraulic  control.  Similarly  the  HF  hypotheses  should 
use  reasonably  consistent  human  resource  strategies. 

3. 3. 5. 5  Closure.  If  these  tests  are  met,  the  HF  hypothesis  and  the  design 
hypothesis  as  a  whole  are  complete  for  one  function.  Go  back  to  step  2.1, 
and  develop  a  design  hypothesis  for  the  next  function. 


SECTION  4 


CRITERIA  FOR  ALLOCATION  OF  FUNCTIONS 


This  section  provides  four  sets  of  criteria  for  determining  the 
allocation  of  functions  (AOF) .  These  criteria  apply  to  functions,  roles  or 
tasks  and  are  to  be  applied  in  making  design  decisions  wherever  a  choice  is  to 
be  made  between  humans  and  machines,  or  automation.  These  criteria  apply 
particularly  to  the  allocation  step  of  subsection  3.3,  and  the  test  and 
evaluation  step  of  subsection  2.5. 

The  four  subsections  which  follow  each  treat  one  set  of  criteria. 
Exhibit  4  shows  how  they  are  related,  and  a  procedure  by  which  they  can  be 
used.  This  is  not  an  artificial  procedure,  but  a  formalization  of  processes 
used  by  successful  designers.  These  four  criterion  steps  are  outlined  below, 
and  are  then  each  treated  by  a  separate  subsection. 

Exhibit  4 

Applying  Criteria  For  Allocation  Functions 


Step  4.1  -  Mandatory  Allocation 


Data  from  the  design  documentation  base  supports  this  process,  and  when 
the  criteria  are  applied  in  the  allocation  of  functions  step  (3.2)  entry  is 
from  the  engineering  hypothesis  (3.1).  This  first  step  deals  with  functions, 
roles  or  tasks  for  which  no  real  judgment  is  required  because  there  are 


mandatory  reasons  for  allocation.  Included  are  cases  in  which  the  required 
performance  is  clearly  beyond  either  human  or  machine  capability,  or 
allocation  is  predetermined  by  legal  or  policy  constraints. 

Three  outcomes  may  occur:  (1)  Allocation  to  automation  or  machine  (A) 
may  be  mandatory,  as  in  the  case  of  high  speed  computation.  (2)  Allocation  to 
humans  (H)  may  be  mandatory,  as  in  the  case  of  policy  control.  (3)  There  may 
be  no  acceptable  allocation  (N)  if  (a)  automation  is  mandatory  but  no  feasible 
technology  exists,  or  (b)  humans  are  mandatory  but  demands  exceed  human 
capability.  This  is  a  common  situation  in  design;  when  no  acceptable 
allocation  exists,  the  function  or  requirement  must  be  redefined. 

Step  4.2  -  Assess  Balance  of  Value 


If  there  are  no  mandatory  reasons  for  allocation,  the  next  most  import¬ 
ant  criterion  is  the  relative  effectiveness  of  humans  versus  machines.  This 
st-r  provides  for  systematic  assessment  of  that  effectiveness.  It  provides 
the  primary  basis  for  decision,  but  is  conditional  on  the  outcomes  of  the  next 
two  steps. 

Step  4.3  -  Utilitarian  and  Cost  Considerations 


This  step  recognizes  that  once  a  human  operator  is  present  and  paid  for, 
he  or  she  can  be  assigned  tasks  which  otherwise  might  be  given  to  machines . 
Aside  from  this  utilitarian  consideration,  the  relative  costs  of  humans  versus 
machines  must  be  considered,  and  can  overrule  the  step  4.2  balance  of  value 
decision. 

Step  4.4  -  Affective  and  Cognitive  Support 


Aside  from  their  effectiveness  in  performing  tasks,  humans  have  unique 
requirements  which  must  be  met.  These  fall  in  two  categories  -  the  affective 
group,  which  includes  human  psychological  and  social  demands,  and  the 
cognitive  group,  which  includes  the  need  of  humans  for  information  upon  which 
to  act . 

Decision 

The  evaluations  of  steps  4.2,  4.3  and  4.4  must  be  weighed  and  a 
decision  made  for  the  allocation  of  each  function,  role  or  task.  When 
combined  with  the  mandatory  decisions  of  4.1,  three  outcomes  are  possible: 

o  Automation  (A) .  Functions,  roles  or  tasks  are  allocated  to 
automation  or  machines,  and  define  a  requirement  for  further  engineer¬ 
ing  development. 

o  Humans  (H) .  Others  are  allocated  to  human  performance,  and  they 
define  a  requirement  for  the  human  factors  development  plan. 

o  No  Outcome  (N) .  Some  functions,  roles  or  tasks  may  have  no  accept¬ 
able  allocation.  The  presumption  is  that  prior  steps  in  the  design 
logic  were  defective,  or  that  requirements  as  defined  are  not 
achievable.  Feedback  to  prior  steps  is  indicated. 


Now  subsections  4.1  through  4.2  will  describe  these  four  sets  of 
decision  criteria  in  detail. 

4.1  MANDATORY  ALLOCATION 

This  subsection  treats  the  first  decision  shown  on  Exhibit  4,  at  which 
we  identify  mandatory  conditions  for  allocation.  This  step  is  usually  taken 
intuitively,  but  is  essential  to  the  allocation  logic.  Exhibit  4.1  shows  the 
four  included  decisions  which  the  step  implies. 


Exhibit  4. 1 

Criteria  For  Evaluation 


Documentation 
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4*1*1  Is  Automation  Mandatory? 

Automation  (or  machine  performance)  may  be  mandatory  if: 

°  Working  Conditions  are  hostile  to  humans  because  of  heat,  cold, 
radiation,  noise,  pressure,  toxicity,  vibration,  acceleration, 
insufficient  pressure  or  insufficient  oxygen. 

o  Regulation,  law  or  policy  requires  automation,  as  in  the  case  of 
certain  alarms  and  safety  sequences. 


o  Safety  of  the  System  requires  an  automatic  response. 

o  Tasks  are  beyond  human  capability  because  of  response  time, 
perceptual  requirements  or  complexity. 

o  Hazards  to  health  or  welfare  are  unacceptable. 

o  Requirements  specify  automation,  as  in  the  engineering  concept,  role 
of -man  statement,  or  design  constraints. 

If  automation  is  mandatory,  go  to  step  4.1.2.  If  not  mandatory,  go  to 
step  4.1.3. 


4.1.2  Is  Automation  Feasible? 


Cases  exist  in  which  automation  is  required  but  is  not  technically 
feasible.  Automation  is  not  feasible  if: 

o  No  Feasible  Engineering  Strategy  is  known. 

o  Costs  of  an  automated  solution  are  clearly  unacceptable. 

o  Time  required  for  development  or  delivery  is  clearly  unacceptable. 

o  Reliability  of  an  automated  solution  will  not  meet  criteria. 

o  Human  Operators  will  not  accept  an  automated  solution. 

If  automation  is  achievable ,  this  validates  step  4.1.1.  Record  a 
mandatory  allocation  in  output  block  4.1.7,  the  list  of  machine  tasks.  If 
not  feasible,  return  by  feedback  to  prior  steps  of  design. 

4.1.3  Is  Human  Performance  Mandatory? 

This  step  is  the  counterpart  of  step  4.1.1,  now  asking  whether  human 
performance  is  mandatory.  Human  performance  is  mandatory  if: 

o  Labor  Agreement  reserves  roles  or  tasks  to  humads. 

o  Policy-Level  Control  is  introduced  into  the  system  by  a  function, 
role  or  task.  Human  users,  commanders,  and  system  owners  must  be  able 
to  exercise  policy  direction  and  on/off  control. 

If  human  performance  is  mandatory ,  go  to  step  4.1.4.  If  not  mandatory, 
exit  this  task  at  4.1.5. 


4.1.4  Is  Human  Performance  Feasible? 


Cases  exist  in  which  human  performance  would  be  required,  but  cannot 


actually  be  achieved  or  provided.  This  step  Is  a  step  frequently  not  taken, 
with  the  result  that  the  end  system  is  at  some  point  not  effective  because 
humans  are  not  able  to  perform  as  required.  Human  performance  is  not  feasible 
if  : 

o  The  Human  Limitations  listed  in  step  4.1.1  apply. 

o  Human  Costs  would  clearly  be  unacceptable. 

o  Human  Reliability  will  not  meet  functional  requirements. 

If  human  performance  is  achievable ,  this  validates  step  4.1.3.  Record 
an  allocation  to  human  performance  in  the  list  of  human  roles  and  tasks,  block 
4.1.6.  If  not  feasible,  return  by  feedback  to  prior  steps  of  the  design  logic. 

4.1.5  Unallocated  Functions 

Functions,  roles  and  tasks  for  which  an  allocation  is  not  mandatory 
either  to  automation  or  to  humans  exit  this  step  to  step  4.2. 

4.2  BALANCE  OF  VALUE  ALLOCATION  OF  FUNCTIONS 

This  subsection  describes  the  major  criterion  by  which  functions  are 
allocated,  which  is  the  operational  merits  of  automation  versus  human  control. 
This  criterion  (Exhibit  4  step  4.2)  applies  when  there  is  no  mandatory  reason 
for  allocation,  and  will  normally  result  in  an  allocation  decision,  but  that 
decision  may  be  overruled  by  steps  4.3  or  4.4,  which  treat  cost  and  human 
acceptance  criteria. 

The  fact  that  humans  perform  a  task  poorly  does  not  necessarily  ensure 
that  machines  can  perform  it  well.  In  this  subsection  we  present  a  decision 
matrix,  the  use  of  which  will  clarify  the  operational  conditions  which  can 
exist  in  comparing  the  merits  of  humans  versus  automation,  and  the 
consequences  of  those  conditions. 


4.2.1  Decision  Space. 


Exlbit  4.2A  represents  a  decision  space  in  which  the  X  axis  is  the 
operational  merit  of  humans,  scaled  from  "unacceptable"  to  "excellent,"  and 
the  Y  axis  represents  the  corresponding  merit  of  automation,  considering  the 
technology  available.  The  X  and  Y  values  of  a  point  in  that  space  will 
represent  the  estimated  relative  predicted  effectiveness  of  automation  versus 
humans  in  performing  a  function,  role  or  task. 


"Merit"  in  this  context  is  a  complex  value  and  must  be  an  engineering 
or  a  human  factors  estimate;  nevertheless,  design  judgment  rests  on  such 
estimates,  with  or  without  use  of  this  matrix.  The  elements  of  merit  Include 
effectiveness,  speed,  reliability  and  availability  of  technology,  depending 
on  the  function  concerned.  Within  the  matrix  are  two  major  areas,  delineated 
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by  the  dotted  line.  Any  function  which  falls  into  the  upper  left  triangle  is 
predicted  to  be  better  performed  by  automation.  Any  function  in  the  lower 
right  is  better  performed  by  humans.  Cases  which  fall  on  the  dividing  line 
are  predicted  to  be  performed  equally  well  by  humans  or  by  automation;  however, 
those  at  the  lower  left  near  the  area  marked  "U"  will  be  performed  poorly, 
while  those  at  the  upper  right  near  the  area  marked  "E"  will  be  performed 
excellently. 


Exhibit  4.2A 

Decision  Space  For  Relative  Control 
Performance  Of  Human  And  Machine 
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(Human  Performance) 


4.2.2  Decision  Matrix 

Exhibit  4.2B  provides  a  more  useful  delineation  of  zones  within  the 
decision  space.  Six  zones  are  differentiated.  Each  represents  a  set  of  cases 
which  should  be  treated  differently.  Six  rules  apply: 

o  Region  Uh  -  Unacceptable  -  Human.  Functions  which  classify  in  this 
area  (far  left,  shaded)  are  predicted  to  be  performed  very  poorly  by  humans. 
These  functions  should  presumably  be  allocated  to  automation. 

o  Region  Ua  -  Unacceptable  -  Automation.  Functions  which  classify 
in  this  area  (bottom,  shaded)  are  predicted  to  be  performed  very  poorly  by 
automation.  They  should  presumably  be  allocated  to  human  control. 


Exhibit  4.2B 

Decision  Matrix  For  Allocation  Of  Functions 
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o  Region  Uah  -  Unacceptable-Automation  and  Human.  The  region  at 
which  Uh  and  Ua  intersect  (lower  left,  heavy  shading)  is  a  special  case. 
Functions  which  classify  in  this  area  are  performed  so  poorly,  either  by 
automation  or  by  humans,  that  they  should  be  avoided  altogether.  These 
functions  represent  infeasible  design,  and  should  be  returned  by  feedback  for 
reconsideration  at  prior  steps  of  the  design  logic. 

o  Region  Pa  -  Preferred  Automation.  Functions  which  fall  in  the 
unshaded  region  at  the  upper  left  might  be  performed  acceptably  by  humans, 
but  automation  is  preferred.  In  general,  such  functions  will  be  allocated 
to  automation.  There  are  exceptions:  (1)  Humans  may  be  selected  for  reasons 
of  cost.  Normally  this  decision  will  be  made  during  the  next  major  step,  step 
4.3.  (2)  Humans  may  be  selected  for  reasons  of  affective  or  cognitive 
support.  Normally  this  decision  will  be  made  during  step  4.4.  On  the  other 
hand,  if  it  is  clear  that  cost  or  human  considerations  will  prevail,  that 
decision  should  be  made  at  once. 

o  Region  Ph  -  Preferred  Human.  Functions  which  fall  in  the  unshaded 
region  at  the  lower  left  might  be  performed  acceptably  by  automation,  but 
human  control  is  clearly  preferred.  These  functions  will  normally  be  allocated 
to  human  control.  Exceptions  exist  as  before:  (1)  Automation  may  be  selected 
to  save  costs ,  or  to  save  crew  weight.  (2)  Automation  may  be  selected  to 
prevent  human  overload.  These  decisions  may  either  be  imposed  later  at  steps 
4.3  and  4.4,  or  they  can  be  made  now. 


o  Region  Pha  -  Preferred  Human  or  Automation.  Finally,  there  is  a 
central  region  representing  those  functions  which  will  be  performed  about 
equally  well  either  by  humans  or  by  automation.  Functions  which  classify  in 
this  region  can  be  allocated  either  way.  Normally,  the  considerations  of  4.3 
and  4.4  will  assist  in  making  an  optimal  allocation,  but  it  will  not  be 
improper  to  allocate  on  the  basis  of  convenience.  The  design  team  can  select 
an  option  for  whatever  reason  they  favor. 

4.3  UTILITARIAN  AND  COST  CONSIDERATIONS 

This  is  the  point  at  which  cost  is  considered.  In  effect,  the  design 
team  is  reviewing  an  allocation  which  has  been  provisionally  made  at  step 
4.2.  That  allocation  may  now  be  modified  or  overruled  in  a  two-step 
procedure:  First,  we  assure  that  where  people  are  present  and  paid  for,  they 
are  fully  utilized.  Then  we  perform  an  informal  cost/value  analysis  focusing 
on  the  balance  between  people  and  automation.  Refer  to  Exhibit  4.3. 


Exhibit  4.3 

Utilitarian  And  Cost  Considerations 


Where  humans  are  present  in  the  system,  paid  for,  and  not  fully 
employed,  we  should  use  them  if  possible.  At  this  step  we  identify  functions 
roles  or  tasks  which  are  otherwise  assigned  to  automation,  and  assign  them  to 
humans  to  minimize  cost  and  complexity.  In  the  process  we  will  contribute  to 
cognitive  support  and  perhaps  job  satisfaction.  "Cognitive  support"  refers 
to  deliberately  planned  human  activity  which  keeps  the  human  operator  active 
and  informed  about  the  system  state.  Cognitive  support  and  job  satisfaction 
will  be  treated  in  detail  by  step  4.4. 


This  step  examines  functions  which  have  been  provisionally  allocated, 
and  identifies  control  requirements  which  can  be  reallocated  to  humans  for 
three  reasons:  (1)  To  save  automation  costs  (the  primary  goal).  (2)  To 
contribute  to  cognitive  support.  (3)  To  contribute  to  job  satisfaction. 

4. 3. 1.1  Is  an  Operator  Available?  First  the  designers  determine  whether 
there  is  a  human  present  at  the  point  represented  by  the  function.  If  humans 
are  present,  qualified  and  not  overloaded  already,  the  designers  can  consider 
reallocating  some  portion  of  the  function  to  human  control. 

4. 3. 1.2  Is  the  Function  a  Suitable  Candidate?  If  a  human  is  available,  the 
function  is  next  examined  for  roles  or  tasks  which  meet  criteria  for  re¬ 
allocation,  as  follows: 

o  Not  Demeaning.  Tasks  which  are  trivial,  demeaning,  or  would  lead 
to  boredom  should  not  be  reallocated. 

o  Not  Too  Difficult.  Tasks  which  would  lead  to  cognitive  overload  or 
increase  probability  of  error  should  not  be  reallocated  to  humans. 

o  Matrix  Position.  Roles  or  tasks  reallocated  should  classify  in  the 
upper  right  of  region  Pha,  on  the  decision  matrix  in  Subsection  4.2. 
They  should  be  tasks  suitable  either  for  humans  or  automation,  tasks 
which  can  be  well  performed  by  either  one. 

4.3.2  Cost-Balance  Consideration. 


This  step  considers  how  system  cost  will  be  affected  by  the  allocation 
of  a  function.  One  objective  of  automation  is  to  minimize  cost.  This  means 
investing  in  automation  when  it  reduces  the  need  for  manpower  or  for  expensive 
levels  of  skill  or  training.  It  also  means  not  investing  if  automation  will 
cost  more  than  the  people  it  replaces.  To  make  this  judgment,  the  designers 
use  whatever  cost  estimating  machinery  is  in  place  on  the  project,  adapting  it 
to  this  assessment.  In  the  absence  of  such  resources  they  will  use  expert 
judgment,  and  they  will  ask  one  of  two  opposing  questions: 

o  Is  Automation  Cheaper?  If  the  function  is  provisionally  allocated 
to  human  control,  they  ask  whether  automation  could  reduce  overall 
system  cost.  They  consider  what  automation  assets  are  forecast  to  be 
available  in  the  system.  If  automation  can  reduce  costs  and  there  are 
no  compelling  reasons  for  manual  control,  the  function  will  be 
allocated  to  automation. 

o  Is  Human  Control  Cheaper?  If  the  function  is  provisionally 
allocated  to  automation,  they  ask  whether  human  control  could  be 
cheaper.  If  so,  and  if  there  is  no  compelling  reason  for  automation 
the  function  Is  allocated  to  human  control. 


The  output  of  these  decisions  is  a  provisional  allocation  for  the 
function  concerned,  subject  to  final  reconsideration  at  step  4.4. 


4.4  ASSESS  AFFECTIVE  AND  COGNITIVE  SUPPORT 


This  subsection  offers  a  final  criterion  by  which  the  designers 
consider  what  we  will  call  "affective  and  cognitive  support."  Earlier  steps 
treated  the  human  operator  as  a  machine  component .  They  considered  only  the 
ability  to  perform  roles  and  tasks,  and  did  not  consider  some  uniquely  human 
characterisitics  which  can  limit  human  performance.  The  fact  that  a  human 
can  perform  a  task  under  one  set  of  conditions  does  not  assure  that  he  or  she 
will  do  so  under  all  conditions.  In  fact,  humans  are  notable  for  their 
unreliable  performance  when  deprived  of  two  kinds  of  support.  The  first  is 
intellectual.  It  is  the  supply  of  information  which  is  needed  to  support 
decisions,  and  we  call  it  "cognitive  support."  The  second  is  psychological 
and  psychosocial,  and  is  a  more  familiar  issue.  We  call  it  "affective 
support"  and  we  will  treat  it  first  (Exhibit  4.4). 


Exhibit  4.4 

Affective  And  Cognitive  Support 


Allocation 

I 

I 

4.4.1  Affective  Support 

Affective  support  is  provided  by  systems  and  organizations  which  are 
designed  to  meet  the  psychological  and  emotional  requirements  of  people. 
These  are  too  numerous  to  list  here,  but  they  include  the  human  need  to  be 
challenged  in  a  non-threatening  way,  but  at  a  level  appropriate  to  personal 
abilities.  People  need  to  feel  that  their  work  is  valued,  that  they  are 
personally  secure  and  on  an  appropriate  career  path,  and  that  they  are  in 
control  of  things  which  concern  them.  These  issues  are  the  concern  of 
industrial  and  organizational  psychologists.  At  this  point  the  developing 
human  subsystem  must  be  evaluated  by  such  professionals  to  determine  whether 
it  will  be  one  in  which  people  will  work  effectively.  If  the  function  being 
considered  may  adversely  affect  affective  support,  it  should  be  considered 
for  reallocation. 


4.4.2  Cognitive  Support 

Cognitive  support  is  a  more  specifically  machine-related  human  need, 
and  is  especially  important  in  automated  systems,  because  those  systems 
frequently  deprive  humans  of  needed  information,  or  of  meaningful  activity. 

4. 4. 2.1  Mental  Models.  A  key  concept  is  that  of  mental  models.  As  a  human 
learns  his  tasks,  he  (or  she)  develops  a  mental  representation  of  the  system, 
its  dynamics  and  its  behavior.  Each  time  he  observes  the  system  or  reads 
instruments,  he  refines  his  mental  model.  He  uses  it  to  understand  what  is 
happening,  and  to  predict  what  the  system  will  do.  He  uses  it  to  forecast 
the  consequences  of  control  interventions  ,  and  .o  plan  control  actions 
accordingly.  The  better  the  model,  the  better  he  will  recognize  abnormalities, 
anticipate  actions,  and  control  the  system.  A  major  objective  of  system  design 
is  to  ensure  that  each  operator  is  both  able,  and  forced  by  his  duties,  to 
maintain  a  mental  model  which  can  support  any  decision  he  will  be  required  to 
make. 

4. 4. 2. 2  Effects  of  Allocation  to  Machine.  When  a  function  is  allocated  to 
automation,  the  operator  or  crew  may  be  deprived  of  information  concerning  the 
events  which  are  automated.  This  creates  a  requirement  for  specific  means  to 
(1)  display  the  needed  information,  and  (2)  ensure  that  operators  will 
assimilate  it.  This  is  a  crucial  issue  in  allocation  of  functions. 

Even  if  instrumentation  is  totally  adequate,  the  operator  or  crew  may 
not  notice,  may  not  remember,  or  may  not  integrate  observed  data  into  the 
model.  If  on  the  other  hand  the  operator  must  personally  decide  and  act,  he 
(or  she)  is  automatically  forced  to  update  the  mental  model.  If  he  is  active 
in  control,  his  model  will  become  progressively  more  detailed,  accurate  and 
finely  calibrated.  In  contrast  when  humans  are  out  of  the  control  loop  and  not 
active  they  lose  control  of  the  model.  Humans  are  not  good  at  monitoring 
tasks.  In  the  monitoring  role  they  learn  more  slowly,  attend  unreliably,  and 
are  less  satisfied  with  their  work. 

4. 4. 2. 3  Evaluate  Cognitive  Support .  If  the  function  under  consideration  has 
been  allocated  to  automation,  we  must  determine  whether  humans  will  be 
deprived  of  information  as  a  result.  The  following  questions  should  be  asked: 

o  Is  Instrumentation  Adequate?  Do  the  instrument  displays  and  other 
sources  provide  all  the  information  which  humans  may  require  for 
normal  performance  and  emergencies?  Does  the  arrangement  of  displays 
reflect  appropriate  priorities? 

o  Are  Humans  Active?  Displays  by  themselves  are  not  adequate.  Does 
the  work  sequence  involve  the  operator  so  that  he  must  acquire  and 
maintain  an  adequate  mental  model?  Will  the  model  be  updated  regularly 
enough? 


o  Is  the  Level  of  Activity  Adequate?  Are  humans  provided  sufficient 


confidence?  People  need:  (1)  A  certain  amount  of  redundancy  in  key 
data.  (2)  A  level  of  detail  and  precision  slightly  greater  than  that 
actually  required  for  decisions.  If  these  are  not  provided,  people 
may  lack  confidence  in  the  data. 


4. 4. 2. 4  Closure .  If  the  provisional  allocation  to  automation  does  not  meet 
these  tests,  revise  the  allocation  of  roles  and  tasks  appropriately. 
Completion  of  this  step  (4.4)  provides  a  completed  allocation  hypothesis. 


SECTION  5 


HUMAN-MACHINE  MODELS 


This  section  presents  some  models  of  the  human-machine  system.  They 
show  the  connectivity  of  elements  within  both  the  machine  and  the  human 
operator,  the  elements  of  the  control  loop,  how  that  loop  can  be  configured, 
and  the  sequences  in  which  parts  interact.  These  models  are  "formal"  in  that 
they  show  form,  rather  than  quantity.  They  are  chosen  from  the  literature, 
and  are  representative  of  the  many  models  which  that  literature  offers. 

These  models  can  be  useful  in  two  ways.  First,  they  can  clarify  the 
basic  nature  of  the  control  process  and  the  relationship  between  systems  and 
humans  as  controllers  or  decision  makers.  Second,  they  can  be  used  analyti¬ 
cally  to  identify  the  sequential  information  processing  steps  which  take  place 
in  systems  control.  In  the  machine  those  steps  are  performed  by  specific 
components  or  software  commands.  In  humans  they  are  performed  by  specific 
organic  subsystems,  but  we  know  much  less  about  human  subsystems  than  about 
those  of  machines.  We  will  refer  to  the  information  processing  steps  as 
"elements  of  performance. "  Mission  success  depends  on  successful  performance 
of  those  elements ,  whether  they  occur  in  the  human  or  in  the  machine .  To 
secure  a  good  allocation  of  functions  we  must  assure  that  each  element  can 
meet  conditions  of  the  control  requirement ,  and  that  the  elements  available 
from  humans  and  from  machines  are  fully  exploited. 

In  this  section  we  will  first  show  two  elementary  models,  to  assist 
those  readers  who  are  not  familiar  with  human-machine  modeling.  Then  in  three 
subsections  we  will  present  three  categories  of  models  which  can  be  applied  to 
the  analysis  of  human-machine  design. 

The  General  Model 


Exhibit  5A  illustrates  the  basic  relationship  between  a  human  and  a 
machine.  Simple  as  it  is,  all  other  models  are  derived  from  this  one.  The 
operator  acts  to  control  the  machine;  through  sensors  he  or  she  observes  the 


Exhibit  5A 

General  Model  Of  Control 


behavior  of  the  machine,  and  the  results  of  control  actions.  He  or  she 
provides  feedback  through  control  action,  either  to  stabilize  the  machine  in 
a  desired  state,  or  to  move  into  new  steps  of  a  task.  This  model  describes 
all  mechanical  work,  including  the  simplest  tool  behaviors. 

The  model  of  Exhibit  5B  shows  additional  elements  of  the  control  cycle, 
as  follows.  The  operator  acts  through  organic  affectors  (1)  -  hands,  feet, 
or  voice.  Those  actions  are  taken,  in  most  cases,  through  controls  (2).  The 
controls,  in  turn,  act  through  actuators  (3),  the  affectors  within  the  system. 
States  and  events  within  the  system  are  detected  by  sensors  (4) ,  which 
display  that  information  through  instruments  (5).  The  operator  acquires 
information  selectively  from  instruments,  through  organic  sensors  -  eyes, 
ears,  touch  (6).  The  human-machine  interface  can  be  seen  to  lie  between  the 
sensors  and  affectors  of  the  operator,  and  the  controls  and  displays  of  the 
machine.  The  elements  shown  here  will  reappear,  with  expanded  detail,  in 
models  which  will  follow. 


Exhibit  5B 

Detailed  General  Model  Of  Control 


Categorization  of  Models 

The  following  three  subsections  each  deal  with  one  category  of  model, 
as  follows : 

o  Levels  of  Automation.  Subsection  5.1  offers  four  simple  models 
which  illustrate  the  hierarchical  relationships  between  operator  and 
system.  These  models  show  linkages,  the  subordination  of  control 
loops,  and  the  delegation  of  control  functions.  They  illustrate  what 
can  be  called  "levels  of  automation." 


o  Elements  of  Cognition.  Subsection  5.2  offers  models  of  information 


processing  within  the  operator.  They  can  assist  with  the  most 
difficult  task  in  allocating  a  function  to  humans:  the  analysis  of 
element-by-element  cognitive  function. 

o  Elements  of  Performance.  Subsection  5.3  offers  models  which  show 
additional  elements  of  human  performance.  The  models  shown  treat  the 
sensory  and  effector  systems,  memory,  and  the  affective  aspects  of 
human  performance. 


5.1  LEVELS  OF  AUTOMATION 

As  often  used  the  term  "levels  of  automation""  has  little  meaning. 

There  is  a  level  of  available  technology  and  a  level  of  investment  in  technol¬ 
ogy;  there  is  also  a  "role  of  man,"  as  defined  in  Subsection  2.1.  But  the 
only  sense  in  which  "level  of  automation"  has  meaning  is  in  describing  the 
hierarchical  relationship  between  operator  and  machine  logic  -  what  humans  are 
required  to  do  or  not  do,  and  how  they  compete  with  or  control  elements  of  an 
automated  system.  The  models  which  follow  will  clarify  some  of  those  rela¬ 
tionships,  and  reveal  their  benefits  and  hazards. 


5.1.1  The  Symmetrical  Control  Model . 

Exhibit  5.1A  represents  the  elements  of  a  system  and  its  automatic 
control  system,  a  hypothetical  case  in  which  automation  and  the  human  operator 
are  assigned  symmetrical  roles.  The  system  (in  the  center)  is  governed  by 
controls  at  the  right,  and  its  state  is  observable  through  sensors  on  the 
left.  The  operator  (above)  receives  information  from  the  displays,  and 
responds  with  control  actions.  The  consequences  of  control  actions  are 
observed  through  the  displays  in  a  continuous  feedback  loop.  In  a  symmetrical 
way,  an  automatic  control  system  senses  system  status  and  affects  control. 


Exhibit  5.1  A 

The  Symmetrical  Control  Model 


A  quick  analysis  shows  that  this  is  an  unacceptable  configuration.  The 
operator  and  the  control  system  are  trying  to  do  the  same  things,  and  they  are 
in  competition  for  control  of  the  system.  They  will  sometimes  undertake 
conflicting  control  strategies.  What  makes  this  danger  more  serious  is  that 
neither  the  operator  nor  the  control  system  can  act  on  the  basis  of  complete 
information,  since  neither  knows  what  the  other  is  planning  to  do.  Either 
can  independently  change  the  configuration  of  the  system;  neither  can  conduct 
a  coherent  control  strategy. 

This  illustrates  that  functions  must  be  specifically  allocated.  It 
also  shows  that  the  operator  and  the  automated  system  must  each  be  informed 
about  the  state  of  the  other.  The  operator  must  know  what  automation  will  do, 
and  the  system  logic  must  "know"  what  the  operator  will  do. 

No  system  is  actually  built  as  shown  in  Exhibit  5.1A,  at  least  not 
altogether.  It  does  frequently  happen  that  single  functions  are  allocated  so 
that  automation  and  human  operators  must  compete  for  control,  or  can  initiate 
competing  control  strategies.  This  has  been  the  underlying  cause  for  several 
recent  technological  disasters.  It  is  vital  that  functional  analysis  should 
detect  such  potential  conflicts,  and  prevent  them  by  specifically  allocating 
functions  to  humans  or  to  automation. 


5.1.2  An  "Allocated"  Model 

We  might  attempt  to  correct  the  defects  of  the  previous  model  by 
providing  a  programmed  division  of  tasks.  Exhibit  5. IB  illustrates  such  a 
system,  in  which  an  "allocator"  exercises  a  predetermined  rule  or  program,  to 
apportion  tasks  between  the  operator  and  automation.  Allocation  might  be 
determined  by  function  (e.g.,  human  controls  weapons  release,  automation 
controls  weapons  platform) ,  or  it  might  be  determined  control  by  control 
(e.g.,  operator  controls  switch  A,  automation  controls  switch  B) .  In  either 
case,  human  and  machine  can  no  longer  oppose  each  other's  actions.  This 


Exhibit  5. IB 
An  “Allocated”  Model 
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configuration  might  be  used  with  caution,  but  never  in  high  level  system 
control . 


First,  notice  that  this  is  what  happens  when  we  use  a  servosystem  or  a 
set-point  controller.  We  offer  the  initial  decision  to  the  operator  and  all 
subsequent  decisions  to  the  machine .  This  is  acceptable  as  a  means  of 
delegating  detailed,  repetitive,  or  high  speed-of -response  tasks  to  auto¬ 
mation,  so  long  as  initiation  and  policy  direction  remain  under  human  control. 

Second,  notice  that  this  configuration  should  be  imposed  only  when  we 
have  thought  the  functions  out  completely,  and  are  willing  to  accept  the 
consequences  that  under  defined  conditions  automation  will  preempt  human 
control.  For  instance  we  might  accept  automatic  seat  ejection  which  the 
pilot  cannot  override.  In  general,  this  kind  of  control  is  imposed  for 
safety  reasons  or  to  preclude  individuals  from  misusing  the  system.  But  for 
the  most  significant  control  functions  this  configuration  is  not  satisfactory 
It  does  not  meet  the  basic  condition  that  humans,  not  machines,  must  exercise 
ultimate  control  and  decide  what  to  do  or  not  do.  Moreover,  we  want  to 
maximize  the  number  of  options  available  to  the  operator,  so  that  he  or  she 
can  respond  to  unpredictable  conditions  with  unpredictable  strategies.  That 
is  one  of  the  major  advantages  of  having  humans  in  the  system. 


5.1.3  A  Hierarchical  Control  System 

Exhibit  5.1C  illustrates  a  control  system  in  which  the  automation  loop 
always  lies  within  an  outer ,  human-driven  loop ,  where  it  can  be  observed  and 
overriden  by  the  operator.  This  model  represents  a  system  in  which  the  inner, 
automation-driven  loop  controls  either  (1)  certain  predetermined  functions,  or 
(2)  the  whole  system  under  normal  conditions.  In  either  case,  the  operator  in 
the  outer  loop  is  able  to  control  directly  if  he  or  she  wishes.  In  addition 
there  is  a  third  operator-to-control  system  loop,  which  enables  the  operator 
to  direct  selectively  whether  automation  will  exercise  control  of  any 
particular  function. 


Exhibit  5. 1C 

A  Hierarchical  Control  System 


5.1.4  Operator  Override  Capability 

The  objectives  of  paragraph  5.1.3  are  met  by  the  configuration  of 
Exhibit  5. ID,  which  is  a  more  realistic  illustration  of  how  such  objectives 
are  met  in  actual  systems.  In  this  model,  the  system  is  normally  controlled 
by  the  automatic  control  system  in  the  center.  The  operator  is  outside,  in 
the  primary  control  loop.  If  the  operator  chooses  to  intervene,  he  or  she 
can  do  so  control  by  control,  and  the  initiation  of  any  manual  control  will 
override  actions  of  the  automatic  control  system. 

Exhibit  5. ID 

Humans  Outside  The  Control  Loop 


5.2  ELEMENTS  OF  COGNITION 

This  subsection  examines  the  human-machine  control  loop  in  further 
detail,  to  identify  some  elements  of  human  cognition.  The  four  models  shown 
here  identify  sequential  information  processing  steps  which  take  place  within 
the  central  nervous  system  of  the  operator,  as  those  steps  are  generally 
understood.  Successful  control  depends  on  the  accomplishment  of  each 
cognitive  processing  step,  steps  which  can  be  called  the  "elements  of 
cognition."  Those  elements  can  be  viewed  as  gates,  filters,  transmission 
paths  and  storage  sites  within  the  human  operator,  who  for  purposes  of  this 
subsection  can  be  viewed  very  much  as  a  computer  or  an  automatic  control 
device.  Successful  design  will  depend  on  functions  which  do  not  exceed  the 
capacities  or  other  limits  of  each  element  of  cognition.  It  will  also  depend 
on  fully  utilizing  the  capabilities  which  those  elements  can  provide. 

These  four  models  may  appear  different  in  structure  and  in  the 
taxonomy  of  elements  which  they  include.  Actually  they  are  not  in  conflict, 
but  represent  differences  in  emphasis.  All  are  equally  valid,  and  all 
represent  accepted  principles  of  human  factors  science.  Users  should  select 
a  model  depending  on  the  function  under  analysis,  and  employ  whichever  model 
proves  most  useful. 
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5.2.1  The  SHOR  Model 


Exhibit  5.2A  is  a  rendition  of  a  model  by  Wohl  (1981).  It  is 
described  as  a  control-theoretic  approach,  in  which  there  is  a  physical 
domain  represented  by  the  system  (plant)  dynamics,  plus  the  instrumentation 
and  control  systems.  On  the  other  side  of  the  human-machine  interface  is  a 
human  information  .processing  domain.  Wohl  identifies  four  main  areas  in  this 
domain  as  follows:  Stimulus  (S)  ,  or  information  organization;  hypothesis 
(H)  generation  and  selection,  which  provides  an  analysis  of  the  situation  and 
its  meaning:  option  (0)  generation  and  selection;  and  finally  response  (R) 
organization  and  execution. 


Exhibit  5. 2 A 

The  SHOR  Model  (From  Wohl,  1981) 


Overlapped 
Mental  Models 


&  Display  System 

The  measurement  system  develops  and  transmits  information  about  the 
system.  This  information  appears  as  instrument  displays  which  act  as  a 
stimulus  to  the  human  operator.  The  operator  maintains  a  mental  model  of  how 
the  plant  works.  Based  on  the  model  and  on  the  instrument  readings,  the 
operator  forms  a  hypothesis  about  the  state  of  the  plant,  including  a 
prediction  of  its  future  behavior.  He  mentally  explores  the  consequences  of 
control  actions,  and  selects  an  option  consistent  with  his  hypothesis  and  the 
system  indications.  If  these  indications  remain  consistent,  he  will  carry 
out  the  selected  option,  which  will  affect  the  system  dynamics  and  initiate 
an  iteration  of  the  SHOR  cycle. 

The  name  SHOR  model  reflects  its  elements  of  stimulus,  hypothesis, 
options  and  response.  The  operator’s  mental  model  can  support  several 
overlapping  hypotheses  at  any  time.  Note  also  the  multiple  internal  paths 
by  which  a  response  can  be  selected  and  organized. 


5.2.2  Levels  of  Human  Behavior 


It  may  be  useful  to  differentiate  control  functions  as  requiring  the 
exercise  of  the  three  levels  of  control  behavior  identified  by  Rasmussen 
(1980).  Exhibit  5.2B  is  derived  from  Rasmussen's  model,  and  is  a  map  of 
several  paths  which  a  control  decision  may  take  during  the  cognitive  control 
process.  At  the  bottom  are  skill-based  actions,  which  require  high  levels  of 
training  and  which  include  both  purely  motor  skills  and  the  stimulus-response 
behaviors  of  the  psychologist's  "well  trained  subjects."  At  the  second  level 
are  rule-based  behaviors,  in  which  responses  can  be  more  flexible  and  are 
formulated  by  the  conscious  application  of  learned  situational  rules.  The 
situation  is  recognized,  associated  with  a  set  of  rules,  and  the  performance 
required  by  the  rules  is  initiated.  Finally  at  the  top  level  are  knowledge- 
based  behaviors  which  provide  the  capability  to  respond  to  unfamiliar 
situations.  The  operator  identifies  a  situation  and  analyzes  it  on  the  basis 
of  mental  models  and  a  general  knowledge  of  machine  behavior.  He  then  plans 
and  executes  rules  to  perform  a  task. 


Exhibit  5.2B 

Cognitive  Levels  Of  Human  Behavior 
(From  Rasmussen,  1980) 
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5.2.3  Temporal  Processing  Sequences 


Derived  indirectly  from  a  model  by  Rasmussen  (1980)  is  that  of  Exhibit 
5.2C,  which  provides  a  relatively  detailed  analysis  of  the  successive  steps 


which  a  decision  may  take,  and  of  the  mental  or  memory  states  which  accompany 
those  steps.  This  was  originally  published  as  a  ladder-shaped  model,  with 
"Evaluate  Alternatives"  shown  as  the  highest  level  processing  step.  The  legends 
should  be  self  explanatory.  Note  that  decision  making  can  require  the  sequen¬ 
tial  exercise  of  all  of  these  steps,  or  can  be  shortcut  by  any  of  the  paths 
represented  by  horizontal  arrows.  These  shunt  paths  have  the  effect  of 
speeding  action  and  of  limiting  the  load  on  higher  level  conscious  processing. 
For  instance,  the  bottom  arrow  defines  a  case  in  which  perception  is  followed 
by  the  automatic  execution  of  a  learned  procedural  response. 


Menial 

(Memory) 

Stales 


Exhibit  5.2C 

Temporal  Processing  Sequences 
(Adapted  from  Rasmussen,  1980) 


Enecuie 

Procedure 


5.2.4  Core  Performance  Areas 


Exhibit  5. 2D  is  a  model  by  Price,  Smith  and  Behan  (1964),  which 
provides  additional  detail  of  the  interfaces  between  operator,  system  and 
environment.  The  legends  are  self  explanatory  except  for  a  few  abbreviations: 
CNS  is  the  central  nervous  system;  S  stands  for  stimulus  and  R  for  response. 
The  terms  "plant"  and  "hardware"  should  be  interpreted  to  mean  "system." 


5.3  ELEMENTS  OF  PERFORMANCE 

Models  in  the  previous  subsection  emphasized  cognitive  processing  and 
treated  the  human  operator  as  comparable  to  a  control  component.  But  in  order 
to  fully  evaluate  human  capabilities  in  control  system  design  we  must 
recognize  the  non-cognitive  aspects  of  human  performance.  These  include  the 
input-output  functions  of  sensation,  perception  and  motor  control,  the  storage 
functions  of  memory,  and  the  affective  aspects  of  behavior  which  make  it 
impossible  to  regard  human  workers  as  equivalent  to  machine  components.  This 


Exhibit  5. 2D 
Core  Performance  Areas 
(From  Price,  Smith  And  Behan,  1964) 
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subsection  includes  four  models  which  show  cognitive  function,  but  relate  it 
to  input -output ,  memory  and  affective  elements  of  performance. 


5.3.1  A  Global  Model 


Exhibit  5.3A  is  a  model  by  Dougherty  (1981)  which  includes  each  of  the 
elements  named  above.  It  is  said  to  be  based  on  a  recent  survey  of  cognitive 
psychology  by  J.  R.  Anderson,  and  represents  elements  of  performance  that  are 
well  accepted  in  the  literature.  Shown  here  are  elements  seen  before  in 
subsection  5.2:  comprehension,  mental  representation  (modeling),  problem 
solving,  memory  and  learning.  To  make  the  model  complete,  Dougherty  adds  the 
mechanisms  of  perception  as  input  and  of  action  as  output.  These  provide  the 
link  between  cognition  and  the  external  system  which  the  operator  will  control 
Goal  direction  is  shown  at  the  top,  and  provides  the  motivation  for  executing 
the  process  sequence  shown  in  the  center.  Emotion  is  shown  at  the  bottom,  as 
i  a  stressor  on  the  process.  This  model  is  globally  complete,  in  that  it 

includes  all  major  elements  which  are  represented  in  the  literature. 


At  the  left  the  sensory  system  is  shown  in  terms  of  separate  senses 
leading  into  perception.  Not  shown  on  this  or  any  other  widely  accepted  model 
is  sensory  buffer  storage.  Such  storage  is  considered  to  exist  but  has  not 
been  the  subject  of  much  applied  research.  Nevertheless,  that  storage  is 
important  in  activities  such  as  scanning  displays  and  evaluating  operational 
situations,  where  what  is  perceived  at  one  instant  is  available  as  a  rapidly 
decaying  information  store,  and  may  or  may  not  be  incorporated  into  memory. 

On  the  right,  the  output  or  motor  functions  are  shown  and  are  classified  into 
an  automatic  and  a  controlled  category.  Automatic  responses  are  those  which 
are  executed  without  conscious  oversight  -  the  highly  learned  motor  responses 
which  lie  on  the  short  processing  paths  of  Exhibit  5.2C. 

Of  particular  value  in  this  model  is  the  separate  representation  of 
short-term  and  long-term  memory.  Because  of  its  small  capacity  and  high 
decay  rate,  short-term  memory  is  a  particular  concern  in  control  system 
design.  It  limits  the  amount  of  input  information  available  to  support 
current  control  actions  and  the  amount  of  information  which  can  eventually  be 
stored  in  long-term  memory.  These  limits  imply  requirements  for  supporting 
information  displays  and  for  buffer  storage  at  the  control  position  to  back  up 
human  memory.  The  user  can  refer  to  the  HEDB  for  more  information  on  short¬ 
term  memory . 

5.3.3  Expanded  Paracognitive  Model. 

Exhibit  5.3C  is  a  model  by  Norman  (1981)  which  offers  an  expanded 
illustration  of  the  affective  elements  of  performance  in  which  cognition  is 
embedded.  Norman  notes  that  cognition  is  not  the  dominating  element  of  human 
behavior,  but  is  embedded  in  more  primitive  processes  of  the  nervous  system. 
These  are  shown  at  the  top,  in  overlapping  circles.  The  basic  flow  of 
cognition  is  shown  at  the  bottom,  with  emphasis  on  steps  of  input-output 
processing  -  sensory  function,  sensory  memory,  pattern  recognition  in  input, 
and  motor  program  selection,  motor  control,  and  effector  function  in  output. 
The  inclusion  of  speech  as  an  output  is  significant  since  that  channel  is 
often  overlooked,  and  is  important  in  any  situation  which  requires  team 
interaction  or  voice  communication. 


5.3.4  The  System  Delta 

The  last  model  is  a  general  model  of  work  behavior  by  Pulliam  (1981)  . 
The  features  of  importance  (Exhibit  5. 3D)  are  the  representation  of  changes 
in  external  system  state,  and  their  corresponding  internal  representation  as 
mental  models,  including  a  model  of  the  driving  "system  delta." 

The  worker  (1)  is  shown  within  a  system  environment  (2) ,  which  includes 
a  current  (actual)  system  state  (3).  The  purpose  of  work  is  to  achieve  a 
desired  system  state  (4).  This  is  true  at  a  global  level:  build  a  house, 
launch  a  satellite.  It  is  equally  true  at  a  micro  level:  adjust  a  voltage, 
saw  a  board.  These  changes  are  accomplished  (or  attempted)  by  the  worker's 
manipulation  of  the  environment  (5),  either  directly  or  through  controls. 

Work  is  performed  by  manipulation  of  affectors  (6),  hands,  feet,  voice;  the 
affectors  are  controlled  by  motor  centers  (7)  of  the  brain.  Those  centers 


Exhibit  5. 3D 

The  System  Delta  (From  Pulliam,  1981) 


are,  in  turn,  controlled  by  the  higher  mental  activity  of  the  forebrain  (8). 
Maintained  in  the  brain  are  many  overlapping  models  of  the  external  world. 
These  include  a  model  of  the  system  actual  state,  as  perceived  by  the  worker 
(9),  and  a  model  of  the  system  desired  state  -  the  goal  to  be  achieved  (10). 
Finally,  there  is  a  model  of  the  difference  between  the  actual  and  desired 
states  -  the  system  delta  (11).  The  system  delta  is  a  mental  model  of  changes 
-  manipulations  by  which  the  desired  state  can  be  achieved.  Obviously  these 
are  dynamic  models,  and  are  constantly  updated  by  new  perceived  infomation. 

All  this  activity  is  driven  by  an  external  imperative  (12)  ,  which 
dictates  the  desired  system  state.  This  may  be  altogether  external,  as  in 
the  case  of  a  shop  foreman,  or  may  be  internalized  as  when  the  work  product 
satisfies  a  need  of  the  worker  himself.  This  model  is  recommended  as  the 
entry  model  in  analyzing  highly  intellectualized  activity  such  as  fault 
finding,  mission  planning,  and  intelligence  analysis.  Such  tasks  provide  few 
overt  clues  to  their  content  since  there  are  few  interactions  with  controls, 
but  they  can  be  analyzed  in  terms  of  the  sequential  contents  of  the  mental 
models  at  (9) ,  (10)  and  (11)  . 
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APPENDIX 


USES  AND  HAZARDS  OF  AUTOMATION 


This  Appendix  provides  four  lists,  suggesting  how  functions  may  be 
appropriately  allocated  to  humans  or  machines.  The  first  list  identifies 
things  which  are  generally  done  well  by  automation,  and  the  second  list 
things  generally  done  well  by  human  beings.  The  third  list  identifies  things 
which  automation  may  not  do  well,  and  some  hazards  of  allocation  to  machines. 
The  fourth  list  identifies  things  humans  may  not  do  well,  and  hazards  of 
allocation  to  human  beings.  List  of  this  kind  have  been  termed  "Fitts 
lists,"  in  recognition  of  an  original  list  published  in  1962  by  the  late  Paul 
Fitts . 


1.  Functions  Performed  Well  by  Machines  and  Automation. 

1.1  Sensing . 

o  Machines  can  sense  forms  of  energy  outside  the  human  range, 
o  Machines  can  be  designed  with  an  arbitrarily  low  response  latency, 
o  Machine  sensors  can  provide  superior  sustained  reliability. 

1.2  Sensory  Buffer  Storage. 

o  Automation  can  provide  arbitrarily  large,  and  long-term  storage. 

1.3  Sensory  Channel  Capacity. 

o  Automation  can  provide  effectively  unlimited  channel  capacity  - 
numbers  of  sensors,  sampling  rates,  bandwidth. 

1.4  Signal/Noise  Characteristics. 

o  Automation  can  provide  good  filtering  of  sensor  data,  to  the 
limits  of  an  ability  to  specify  filtering  in  terms  of  spectra  or 
sequential  characteristics. 

o  Automation  can  recognize  and  respond  to  small  changes  in  signal 
level.  It  can  recognize  slowly  developing  changes,  or  changes  in 
small  increments . 

o  Automation  can  be  "vigilant"  contrasted  to  humans,  in  reliably 
detecting  energy  or  signals. 

1.5  Pattern  Recognition. 


o  Automation  is  reliable  for  detecting  simple,  fully  predicted 
(programmed)  information  patterns. 


o  Automation  is  good,  fast  and  accurate  at  formatting  pattern 
displays  for  human  analysis. 

o  Automation  can  be  "vigilant"  within  its  pattern-recognition 
limitations . 

1.6  Monitoring . 

o  Automation  is  an  effective  monitor,  within  its  sensing  and  pattern- 
recognition  limits. 

o  Automation  can  provide  effective  oversight  to  humans,  who  are 
notably  fallible  in  monitoring  tasks. 

o  Automation  does  not  become  bored,  fall  asleep,  shift  its  attention, 
or  become  disaffected. 


1 . 7  Information  Storage. 

o  Automation  can  provide  effectively  unlimited  storage  of  information 
That  storage  can  be  reliable  and  fast. 

o  Automation  can  provide  unlimited  analog  data  storage,  but  only  at 
the  cost  of  distortion. 

1.8  Information  Recall. 

o  Automation  can  provide  accurate,  reliable,  high-speed  data  recall. 

1.9  Response  (Procedural) . 

o  Automation  can  respond  quickly  to  control  signals  (microsecond  lag) 


o  Automation  is  effective  in  performing  repeated,  detailed,  precise 
routine  tasks.  These  tasks  must  be  fully  predictable  and  specifiable 
as  a  program  sequence. 

o  Automation  can  handle  a  high  task  bandwidth  -  many  steps  at  once, 
high  speed  procedures,  complex  tasks.  These  must  be  programmable. 

o  Automation  is  reliable  in  procedural  tasks,  limited  only  by 
equipment  design,  component  reliability,  and  the  fact  that  it 
is  rarely  possible  to  anticipate  all  the  program  contingencies. 

1.10  Deduction. 

o  Automation  (computing  machinery)  is  outstanding  at  performing 
deductive  tasks,  within  the  limited  range  of  a  programmable 
algorithm.  Artificial  intelligence  may  soon  extend  that  range. 

o  Automation  is  quicker  and  more  reliable  than  humans  in  recognizing  a 
data  set  as  a  member  of  a  class,  within  a  programmable  algorithm. 
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o  Automation  Is  appropriate  for  tasks  such  as  timeline  analysis.  It 
can  rapidly  produce  a  system  optimization,  within  the  programmer's 
ability  to  quantify  variables  and  value  judgments. 

o  Automation  can  reduce  human  cognitive  workload  by  automatic 
situation  assessment,  preplanning  strategies,  and  escape  routines. 

o  Automation  can  anticipate  emergencies. 

o  Automation  can  reduce  human  perceptual  and  cognitive  loads  by 
prioritizing  data  for  display. 

o  Automation  is  effective  in  fault  diagnosis,  within  a  programmed 
paradigm.  It  has  a  limited  diagnostic  repertoire,  but  performs 
reliably  within  that  range.  Machine  diagnoses  must  be  confirmed  by 
humans . 

1.11  Induction. 

(No  practical  capability  for  automatic  induction  has  been  shown.) 

1.12  Computation. 

o  Machines  calculate  more  rapidly  and  reliably  than  humans,  except 
that  input-output  rates  for  some  computations  may  be  higher  for 
humans . 

o  Automation  is  efficient  in  scheduling,  resource  allocation. 

o  Automation  provides  the  speed  of  computation  required  for  tasks 
such  as  weapons  delivery  and  fire  control. 

o  Automation  Is  ideal  as  a  tool  for  computing  navigation  and 
controlling  communications. 

o  Automation  can  reduce  human  cognitive  and  perceptual  workload  by 
integration  of  data  for  displays. 

o  Automation  can  improve  human  control  performance  by  providing 
predictive  and  quickened  (feedback)  displays. 

1.13  "Judgment . 11 

(The  term  "judgment"  resists  definition  but  requires  the  interaction 
of  value  with  memory  and  deductive  logic.  Machines  do  not  as  yet 
provide  anything  resembling  judgment,  but  with  advances  in  artificial 
intelligence  will  probably  do  so.) 

1.14  Responsibility . 

(By  its  definition,  responsibility  must  be  assigned  to  a  human.) 
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1.15  Power  and  Force. 

o  Machines  can  exert  large  forces  smoothly  and  precisely. 

o  Machines  can  provide  power  limited  only  by  design  and  cost. 

o  Machines  can  exert  small  forces  more  precisely  than  humans, 
although  in  certain  complex  cases  human  control  of  small  forces  is 
more  precisely  applied. 

1.16  Manipulation. 

o  Machines  can  manipulate  their  own  integral  parts  with  high  speed, 
reliability  and  precision. 

o  Machines  have  a  limited  capability  to  grasp  objects.  Within  that 
capability,  they  perform  more  reliably  than  humans,  but  not  in  all 
cases  more  precisely. 

o  Automatic  speed  of  manipulation  is  good  in  simple  routines. 

o  Automation  is  an  effective  means  of  manipulating  flight  trajectory 
and  attitude  controls. 

o  Automation  is  effective  in  engine  and  power  control. 

o  Automation  can  perform  manipulations  continuously  for  long  periods 
of  time. 

o  Automation  can  perform  tracking  tasks  at  relatively  high  and  low 
speeds,  but  within  human  bandwidths,  humans  track  more  flexibly,  and 
adapt  more  effectively  to  complex  tracking  paths. 

1.17  Sensitivity  -  Informational. 

o  Machines  are  not  perturbed  by  human  emotional  and  situational 
problems.  They  do  not  fall  in  love,  or  suffer  loss  of  morale. 

o  Automation  is  appropriate,  within  programmability,  to  perform  long 
duration  missions  where  humans  would  suffer  from  Isolation,  sensory  or 
perceptual  deprivation. 

o  Automation  is  appropriate  for  tasks  which  humans  find  distasteful. 

o  Automation  is  appropriate  for  tasks  in  which  humans  suffer  from 
fatigue,  or  informational  overload. 


1.18  Sensitivity  -  Physical 


o  Machines  can  be  designed  to  degrade  very  slowly  in  time,  and  to 
provide  sustained  performance  in  spite  of  wear  and  physical  accident. 


o  Machines  are  appropriate  to  replace  humans  in  hazardous  military 
missions,  hostile  exploratory  environments,  hostile  industrial 
environments,  and  in  restricted  physical  spaces. 

1.19  Economics . 

o  Machines  or  automation  can  replace  most  human  functions,  given 
development  funding,  professional  talent,  and  time.  All  of  these  are 
severely  limited  resources. 

o  Machines  can  be  economically  developed  when  a  large  number  of  units 
will  replace  a  large  number  of  human  functions.  Even  where  machines 
are  much  more  effective,  human  performance  may  be  more  economic  if  only 
a  few  cases  are  involved. 

o  Automation  can  be  especially  cost  efficient  in  aircraft  and  in  space 
missions,  where  the  human  costs  of  body  weight  and  of  life  support 
equipment  are  high. 

o  Machines  can  be  expendable. 


Functions  Performed  Well 


by  Human 


Beings . 


2.1  Sensing. 


o  Humans  have  several  sensory  systems,  which  can  detect  a  wide 
variety  of  stimuli.  Several  of  them  (vision,  hearing  and  touch)  are 
more  sensitive  than  any  available  mechanical  sensor,  except  for  a  few 
devices  of  narrow  bandwidth. 


o  Human  senses  are  highly  controlled.  Vision  is  capable  of  very  rapid 
fixation,  and  hearing  has  an  equivalent  practical  capability. 

o  Human  senses  are  capable  of  discriminating  meaningful  signals  in  the 
presence  of  noise,  and  of  rapid,  subtle  pattern  recognition. 

o  At  the  sensory  level,  humans  have  a  very  high  bandwidth,  and 
an  ability  to  sample  that  range  selectively  for  meaningful  information. 
That  capability  is  limited  by  processing  bandwidth. 

2.2  Sensory  Buffer. 

o  Human  sensory  data  are  held  in  the  equivalent  of  buffer  storage 
for  a  second  or  so.  During  this  time  the  data  decay,  but  are 
available  for  reevaluation  by  conscious  and  subconscious  processes  of 
the  nervous  system.  These  data  are  used  to  select  data  for  further 
processing,  and  to  control  the  continued  focus  of  attention. 


o  Contents  of  the  sensory  buffers  are  high  for  vision  and  hearing, 
but  are  limited  for  smell,  touch,  temperature,  taste,  balance, 
kinesthetics  and  pain. 

o  Contents  of  sensory  buffers  are  highly  focused,  with  fine  detail 
at  points  of  fixation  and  diminishing  detail  for  peripheral  data. 
Contents  are  highly  dependent  on  the  direction  of  attention.  Humans 
should  be  used  as  sensors  under  conditions  which  assist  the  focus  of 
attention  prior  to  critical  events.  This  focus  can  be  provided  by 
automatic  alarms. 

2 .3  Sensory  Channel  Capacity  and  Sensory  Processing. 

o  Sensory  processing  provides  an  ability  to  integrate  sensory  data, 
without  conscious  intervention,  against  a  single  target.  Thus  a 
surface  is  perceived  as  "rough"  due  to  integrated  visual  and  tactile 
data. 

o  Humans  should  be  used  with  automated  sensing  and  storage  aids,  for 
tasks  which  require  brief  periods  of  high  perceptual  demand. 


2.4  Signal/Noise  Characteristics. 

o  In  general,  human  senses  are  superior  to  existing  automation  in 
discriminating  meaningful  signals  in  the  presence  of  noise.  They 
should  be  assisted  by  the  specialized  capabilities  of  automation,  which 
can  provide  prior  spectral  and  formula-based  filtering. 

2.5  Pattern  Recognition. 

o  Humans  are  superior  to  existing  machines  in  recognizing  patterns, 
especially  in  the  presence  of  interference.  They  can  recognize  spatial 
patterns,  spectral  patterns  in  sound,  and  temporal  patterns  in  events. 

o  Humans  can  use  pattern  recognition  to  simplify  complex  input  data, 
by  formulating  meaningful  "wholes." 

o  Humans  can  recognize  patterns  in  spite  of  changes  in  size, 
orientation,  rotation,  or  distortion. 

o  Humans  can  learn  to  distinguish  patterns  in  displays  -  patterns  of 
lights,  correlations  in  indicators,  sequences  of  indicator  events. 

This  capability  is  unreliable,  and  should  be  assisted  by  automated 
integration  of  data,  or  automated  alarms,  when  feasible. 

o  Humans  have  a  capability  for  "perceptual  filling,"  which  enables 
them  to  identify  a  whole  pattern  from  a  few  cues,  when  most  of  the 
data  are  obscured.  Thus  a  hunter  "sees"  a  squirrel  among  the  leaves 
by  a  glimpse  of  its  tail.  This  capability  can  lead  to  error  or 
illusion,  especially  when  the  observer  has  a  bias  or  prior  expectation. 


2.6  Monitoring. 

o  Humans  are  effective  monitors  for  brief  periods,  to  identify 
complex  events  given  proper  training,  and  given  an  alerting  signal. 

o  Humans  should  be  used  for  monitoring  tasks  with  automated  support. 

o  Humans  should  be  used  with  an  artificially  active  routine,  to  ensure 
their  systematic  attention  and  active  analysis  of  displayed  data. 

o  Incorporate  automated  alarms  where  possible.  Do  not  permit  a 
condition  where  multiple  alarms  may  confuse  the  operator. 

o  Provide  ground  communications  support  to  critical  airborne 
monitor  requirements. 

2 . 7  Information  Storage. 

o  Humans  have  the  general  ability  to  store  large  amounts  of 
information,  and  to  recall  pertinent  information  rapidly.  This 
ability  is  limited  by  the  structure  of  memory,  which  includes  a  long¬ 
term  memory  (LTM)  and  a  short-term  memory  (STM) ,  with  different 
characteristics . 

o  Read-in  channel  capacity  to  memory  is  limited  by  the  capacity  of 
STM,  which  can  attend  to  only  about  1.5  sensory  channels,  and  hold 
about  5-7  significant  data  at  one  time.  Those  data  fade  rapidly, 
and  are  replaced  with  new  experience  data,  unless  reinforced  by 
rehearsal  or  active  task  performance. 

o  Data  from  STM  may  be  stored  in  LTM,  depending  on  their  perceived 
importance,  their  active  use,  and  the  presence  or  absence  of 
interfering  experience. 

o  When  experiential  or  display  data  appear  rapidly,  humans  are 
unable  to  retain  those  data  in  STM  and  use  them  to  formulate  a 
response.  Use  humans  in  tasks  which  have  momentary  high  data  input 
rates  by  providing  buffer  data  displays,  or  buffer  memory  available 
on  command. 

o  Human  memory  for  patterns,  strategies,  principles,  and  contingencies 
of  action  is  superior  to  that  of  a  machine.  This  memory  depends  on 
the  linkage  of  what  is  remembered  to  prior  experience,  and  to  the 
perceived  needs  of  the  observer. 

o  Humans  can  remember  analog  sensory  data  which  form  meaningful 
patterns,  with  a  hi^h  fineness  of  relative  scale  (frequencies, 
positional  data) . 
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2.8  Information  Recall. 


o  Human  memory  is  unique  in  providing  storage  based  on  a  hierarchy  of 
importance.  As  a  result,  data  perceived  as  important  are  readily 
recalled,  and  other  data  are  recalled  more  slowly  and  less  reliably. 

o  For  completely  random  recall ,  human  memory  is  superior .  For  planned 
data  retrievals,  and  compared  to  machines,  human  recall  is  slower,  less 
reliable,  and  situation-dependent.  Machines  are  better  only  when  the 
data  addresses  have  been  identified,  and  the  data  placed  in  an 
addressable  register. 

2.9  Response  (Procedural) . 

o  Humans  can  exercise  a  wide  repertoire  of  learned  procedural 
responses,  and  can  adjust  or  modify  those  responses  to  meet  contingen¬ 
cies.  Response  repertoire  is  limited  by  learning  rates:  reliability 
may  be  low  compared  to  machines . 

o  Pilots  or  operators  should  be  supported  with  simulators  to  maintain 
a  repertoire  of  required  psychomotor  responses.  Build  simulators  into 
operational  equipment  (embedded  training)  to  maintain  repertoires  of 
psychomotor  skills. 

2.10  Deduction . 

o  Humans  have  an  advantage  in  flexibility  and  universality  in 
deduction.  However  they  are  generally  inferior  to  machines  because  of 
limited  speed,  parallel  capacity,  and  reliability. 

o  Humans  are  able  to  learn  adaptively  and  to  profit  deductively  from 
prior  experience,  including  very  recent  task  events. 

o  Humans  are  able  to  handle  deduction  for  low  probability  events, 
which  cannot  be  economically  programmed  into  a  machine. 

o  Humans  are  flexible  and  can,  in  effect,  change  their  own  deductive 
programming  when  necessary . 

o  Humans  can  consider  and  evaluate  a  wide  range  of  alternatives , 
drawing  on  their  flexible  and  value-based  memory  store.  They  can 
formulate  alternatives  which  were  not  foreseeable  at  the  time  of 
system  design. 

o  Humans  can  develop  new  deductive  responses.  In  case  of  failure, 
they  can  reconfigure  a  system,  or  invent  a  new  escape  strategy. 

o  Humans  can  accomplish  similar  objectives  by  alternate  means,  or  if 
an  original  objective  is  not  achievable,  they  can  formulate  alternate 
objectives . 


o  Human  deduction  is  adaptable  but  fallible.  For  tasks  where  errors 
in  deduction  may  be  serious,  provide  ground  communication  support. 
Consider  developing  artifical  intelligence  routines  to  evaluate  and 
verify  human  decisions . 

o  Human  deduction  provides  the  best  full-r. nge  solution  to  fault 
diagnosis  or  trouble-shooting.  Human  fault  diagnosis  is  slow,  and 
may  not  follow  optimal  logical  pathways.  Support  human  trouble¬ 
shooting  with  built-in  tests,  and  with  automated  diagnostic  procedures. 

2.11  Induction. 

o  To  this  date,  humans  alone  can  perform  inductive  reasoning. 

This  makes  it  possible  for  humans  to  generalize  from  a  few  data,  and 
to  generate  completely  new  solutions  not  derivable  by  deductive  logic. 

o  Humans  can  explore  and  experiment,  both  actively  and  as  a  mental 
process.  This  may  lead  to  both  good  and  bad  reponses.  Design  systems 
so  that  the  human  tendency  to  explore  cannot  lead  to  damage  or  failure. 

o  Inductive  logic  can  lead  to  rapid,  intuitive  successes  in  diagnosis. 

o  Humans  are  able  to  solve  problems  by  heuristic  strategies. 

o  Humans  are  able  to  generate  classes  of  events,  and  recognize 
members  of  a  class . 

2.12  Computation. 

o  Humans  have  an  occasional  advantage  in  input-output  speed.  For 
simple  computations,  they  can  perceive  quantities,  compute  an  answer, 
and  take  action  more  rapidly  than  the  data  can  be  read  to  and  from  a 
machine . 

o  Humans  are  better  than  machines  at  analyzing  and  evaluating 
geometrical  relationships. 

o  Humans  are  much  better  than  machines  at  recognizing  and  correcting 
errors. 

2.13  "Judgment. " 

o  Humans  are  capable  of  exercising  combinations  of  inductive  logic, 
deductive  logic,  and  memory  to  relate  action  to  values.  This  requires 
the  evaluation  of  conceptual  and  other  data  not  quantifiable,  and  is  a 
function  which  to  this  date  cannot  be  performed  by  machines.  Use 
humans  where  judgmental  decisions  are  required. 


2.14  Responsibility . 

o  Humans  are  ultimately  responsible  for  h.ow  a  system  is  employed,  and 
for  the  consequences  of  system  failure.  Identify  the  points  in  a 
system  where  command  decisions  are  required,  or  where  responsibility 
must  be  exercised.  Use  automation  to  ensure  that  information  is 
displayed  to  the  person  responsible.  Ensure  that  the  system  is 
designed  so  that  the  responsible  person  can  in  fact  intervene  and 
exercise  control.  Ensure  that  critical  historic  data  are  collected 
and  preserved. 

2.15  Power  and  Force. 

o  Use  humans  to  provide  power  or  force  when  the  required  action  is 
momentary,  within  human  capability,  and  when  use  of  humans  is  more 
economical . 

o  Use  humans  to  provide  finely  modulated,  low  levels  of  power  or  force 

2.16  Manipulation. 

o  Humans  have  a  flexible  ability  to  grasp  and  manipulate  objects, 
within  a  narrow  range  of  power  and  speed .  Within  that  range  they  are 
generally  superior  to  machines . 

o  Humans  can  perform  fine  manipulations  required  in  assembly  tasks, 
soldering,  calibration,  and  adjustment. 

o  Humans  can  perform  manipulations  in  a  non-programmable  routine ,  and 
with  rapid  feedback  from  the  senses. 

o  Humans  can  perform  complex  tracking  tasks .  Although  machines  are 
superior  in  high-speed,  multichannel  and  continuous  tracking,  humans 
can  track  more  finely,  more  adaptively,  and  with  flexible  tracking 
stragegies . 

o  Human  tracking  is  less  dependable  than  that  of  a  machine,  and  cannot 
continue  over  long  periods  of  time, 

2.17  Sensitivity  -  Informational. 

o  Humans  can  operate  for  short  periods  under  a  variety  of  unpredict¬ 
able  overloads  and  information  noise.  This  capability  is  motivation 
dependent . 

o  Humans  can  adjust  to  overload  by  reducing  their  processing  rate, 
under  conditions  which  would  cause  an  automated  system  to  fail. 


o  Humans  are  able  to  effectively  filter  meaningful  data  from  noise 
(see  2.4). 


o  This  capability  varies  with  individuals.  Select  humans  in  critical 
jobs  by  testing  for  performance  under  stress,  threat  and  informational 
overload . 

2 . 18  Sensitivity  -  Physical. 

o  Humans  can  handle  a  wide  range  of  temporary  physical  stresses  and 
overloads,  within  a  limited  range.  Use  humans  where  these  stresses  are 
occasional,  and  where  human  performance  is  the  least  expensive  choice. 

2.19  Economics. 

o  In  general,  humans  are  a  high-cost  component.  Trained  people  are 
expensive.  They  require  elaborate  work  facilities,  organizational 
support,  and  overhead  costs.  Use  automation  when  it  will  reduce  the 
cost  of  task  performance. 

o  Use  humans  where  a  limited  number  of  units  will  be  required,  and 
where  the  costs  of  developing  automation  are  therefore  not  justified. 

o  Use  humans  where  automation  is  not  feasible,  at  the  current  state 
of  technology . 

o  Use  humans  for  utilitarian  functions  (see  subsection  4.3). 


Limitations  and  Hazards  of  Automatic  Performance . 


3.1  Sensing. 

o  Machine  sensors  have  poor  signal  detection  in  the  presence  of  noise. 
When  noise  spectra  overlap,  they  are  subject  to  false  detection  or  to 
failure  to  detect.  They  are  easy  to  jam. 

o  Machine  sensor  systems  are  relatively  insensitive  to  direction,  slow 
and  awkward  to  orient  in  direction. 

o  Machine  sensors  can  provide  lower  detection  thresholds  than  human 
sensors,  but  these  are  in  general  narrow-band  and  high-cost  devices. 

3.2  Sensory  Buffer  Storage. 

o  Machine  buffer  storage  has  effectively  unlimited  capacity,  but  is 
unable  to  address  collected  data  meaningfully,  unable  to  assign 
priority  to  data,  and  unable  to  purge  noise  from  meaningful  data. 


3.3  Sensory  Channel  Capacity  and  Processing. 


3.4  Signal  to  Noise  Characteristics. 

o  Electronic  filters  can  provide  superior  noise  discrimination,  but 
only  where  noise  can  be  specified  in  terms  of  discrete  spectra. 

3.5  Pattern  Recognition. 

o  Automated  systems  have  a  limited  capacity  to  recognize  meaningful 
patterns,  and  are  reliable  within  that  range.  They  recognize  only 
preprogrammable  and  non-subtle  discriminations.  Humans  should  be 
included  in  an  automated  system  where  patterns  must  be  detected. 

3.6  Monitoring. 

o  Automation  provides  reliable  monitoring,  but  this  capability  is 
limited  by  the  ability  of  machines  to  detect  patterns  and  meaning. 

An  automatic  monitor  can  detect  only  preprogrammed  contingencies. 

3.7  Information  Storage. 

o  Automatic  storage  is  "dumb"  storage.  It  stores  every  datum 
encountered.  It  cannot  prioritize  data,  cannot  distinguish  data  from 
noise,  cannot  assign  meaningful  addresses  to  data  except  addresses 
based  on  time  and  data  channel. 

o  Automation  does  not  store  data  economically  without  human 
intervention. 

o  Automation  cannot  store  analog  data  without  distortion. 

3.8  Information  Recall. 


o  Automated  recall  is  inefficient  because  of  the  lack  of  an  optimal 
addressing  structure.  For  many  applications  humans  should  be  present 
in  the  loop  to  evaluate  and  readdress  recalled  data. 

3.9  Response  (Procedural) . 

o  Automation  is  difficult  and  expensive  to  program.  Usually  it  is 
not  possible  to  program  for  all  possible  contingencies,  both  because 
of  the  costs  of  programming,  and  because  the  contingencies  cannot  be 
anticipated . 

o  Automatic  programs  can  remain  full  of  bugs  -  "surprises"  -  long 
after  they  are  believed  perfect. 

o  Automated  responses  are  relatively  inflexible.  Flexibility  can  be 
achieved  only  at  high  cost. 

3.10  Deduction. 


o  To  achieve  a  complexity  equal  to  that  of  a  human  would  require 
massive  computers,  unreasonable  costs  and  development  times. 


o  The  cost  of  maintenance  rises  with  capability. 


o  Deductive  ability  is  limited  by  inability  to  perceive  organization 
in  data.  A  limited  capacity  to  detect  organization  is  achieved  only 
with  large  machines,  elaborate  programming,  and  difficult  prior 
analysis . 

3.11  Induction. 

(No  applied  inductive  capability  has  been  demonstrated  for  automation.) 

3.12  Computation. 

o  Machines  have  poor  capability  to  detect  errors  in  operation  or  in 
procedure . 

o  Machines  have  poor  capability  to  correct  errors  when  detected, 
o  Errors  in  machine  computation  may  cascade  into  total  process  failure. 

3.13  "Judgment". 

(Machines  cannot  exercise  anything  resembling  Judgment.) 

3.14  Responsibility. 

(Responsibility  cannot  be  assumed  by  a  machine.) 

3.15  Power  and  Force. 

o  Within  the  middle  range  of  human  capability,  humans  can  modulate 
power  and  force  more  finely  than  machines. 

3.16  Manipulation. 

o  To  date,  machines  have  limited  capability  to  grasp  objects. 

o  For  some  applications  within  the  human  range,  humans  can  manipulate 
more  precisely,  and  human  sensor-to-affector  feedback  is  superior. 

o  Within  the  human  range,  humans  can  track  single  targets  more 
precisely  and  adjust  more  quickly  to  changes  in  behavior  of  the  target 
being  tracked. 

3.17  Sensitivity  -  Informational. 

o  Machine  logic  is  vulnerable  to  disruption  by  noise  in  the  input 
signals . 

o  Input  overloads  may  lead  to  failure. 

o  Resistance  to  informational  overload,  jamming  and  noise  is  achieved 
only  at  a  high  programming  cost. 
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3.18  Sensitivity  -  Physical. 


o  Machines  are  vulnerable  to  minor  damage.  They  break  down  completely 
when  single  components  fail.  They  do  not  "heal." 


3.19  Economics. 


o  Automation  of  all  but  the  simplest  functions  is  achieved  only  at 
high  dollar  cost,  a  high  cost  in  development  time,  and  by  diverting 
limited  engineering  talent  to  the  problem  concerned. 


o  Automation  typically  cannot  be  afforded  to  replace  humans  unless 
many  people  are  replaced  for  an  extended  time. 


Limitations  and  Hazards  of  Human  Performance. 


4.1  Sensing . 

o  Human  senses  have  a  relatively  high  response  latency, 
o  The  effectiveness  of  human  senses  is  reduced  by  fatigue, 
o  Human  senses  are  damaged  by  signal  overloads . 

4.2  Sensory  Buffer  Storage. 


o  Information  detected  by  human  sensors  is  available  for  only  a  few 
seconds  at  most.  If  not  picked  up  in  short-term  memory  (STM),  it  is 
lost . 


4.3  Sensory  Channel  Capacity. 


o  Compared  to  machines,  humans  have  very  limited  sensory  channel 
capacity . 


o  Human  attention  is  highly  focused.  Very  limited  information  is 
collected  outside  the  point  of  focus. 


o  Humans  cannot  effectively  share  atcention.  They  tend  to  fix  on  one 
signal  or  problem,  and  disregard  others  of  equal  or  greater  value. 


4.4  Sensory  Processing  and  Signal/Noise  Characteristics. 


o  The  ability  to  perceive  meaningful  information  in  sensory  data  is 
limited  by  experience  and  training. 


o  Human  ability  to  "fill"  patterns  can  lead  to  false  perceptions. 


o  Humans  tend  to  fulfill  expectations  in  perception,  regardless  of 
the  data  input. 
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4.5  Pattern  Recognition. 

o  Human  pattern  recognition  in  the  presence  of  noise  decays  rapidly 
with  fatigue,  or  high  levels  of  demand. 

o  Human  pattern  recognition  fails  when  the  interfering  noise  is 
meaningful. 

o  Humans  recognize  distance,  speed  and  clearance  by  pattern 
recognition,  but  their  performance  is  inferior  to  that  of  automation. 
Humans  underestimate  greater  distances.  Estimation  of  distance  and 
speed  is  perturbed  by  conditions  such  as  haze. 

4.6  Monitoring. 

o  Humans  are  notably  poor  monitors,  and  should  not  perform  monitoring 
tasks  for  more  than  a  few  minutes  without  automated  support. 

o  Human  monitoring  is  further  impaired  when  there  are  a  large 
numbers  of  displays,  information  inputs,  or  critical  events  to  be 
detected. 

o  Humans  typically  think  about  other  things  in  a  monitoring  situation 
They  cannot  avoid  this  tendency.  There  is  no  training  or  motivational 
fix . 

o  Humans  tend  to  become  complacent  during  periods  of  no  alarm, 
o  Humans  cannot  respond  to  more  than  one  alarm  signal  effectively, 
o  Humans  are  subject  to  initiating  false  alarms. 

4.7  Information  Storage. 

o  Human  STM  has  limited  capacity  and  a  fast  decay  rate.  It  is  a 
severely  limiting  factor  in  human  channel  capacity. 

o  Human  long-term  memory  is  unreliable. 

4.8  Information  Recall. 

o  Human  recall  is  unreliable,  and  varies  with  time  and  circumstances. 

4.9  Response  -  Procedural. 

o  Human  procedural  responses  are  single-channel. 

o  Under  stress,  humans  revert  to  prior  behavior  patterns  in 
preference  to  recently  learned  procedures . 


o  Under  stress,  humans  revert  to  simpler  and  more  intuitive 
behaviors,  In  preference  to  learned  procedures. 


o  Humans  will  not  read  procedures  if  they  think  they  remember  them, 
o  Humans  will  not  recheck  their  performance  of  a  procedure. 

4.10  Deduction. 

o  Human  deduction  is  a  single -channel  process. 

o  Human  deduction  is  very  slow  compared  to  machine  logic. 

o  Human  deduction  is  perturbed  by  emotion,  prior  opinion,  personal 
interests,  stress. 

o  Human  deduction  is  not  reliable,  and  reaches  differing  conclusions 
on  sequential  tries. 

o  Humans  tend  to  underestimate  or  disregard  hazards,  although 
deductively  aware  of  probable  consequences. 

o  Humans  tend  to  persist  in  error  behaviors  after  they  are  deductively 
aware  of  the  error. 

4.11  Induction. 

o  Humans  cannot  exercise  inductive  logic  on  demand. 

4.12  Computation. 

o  Human  computation  is  slow,  inaccurate  and  unreliable. 

o  Human  judgments  concerning  optimal  strategy  -  game  theoretic  or 
decision  theoretic  estimates  -  are  subject  to  intuitive  errors. 

o  Human  estimates  or  mental  computation  of  statistical  conditions 
are  subject  to  systematic  errors.  Humans  overvalue  recent  data  and 
events.  They  evaluate  data  using  subjective  criteria.  They  under¬ 
value  the  severity  of  an  emergency  once  it  is  detected. 

4.13  "Judgment.” 

o  Humans  may  be  unable  to  exercise  judgment  when  circumstances  do 
not  provide  a  feeling  of  confidence. 

4 . 14  Responsibility . 

o  Humans  may  seek  to  evade  responsibility, 

4.15  Power  and  Force. 

o  Humans  can  generate  only  limited  power  and  force,  for  limited 
periods  of  time. 
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4.16  Manipulation. 

o  Human  manipulation  cannot  be  standardized  from  trial  to  trial. 

o  The  precision  of  human  manipulation  degrades  at  high  power  and 
force  loadings. 

o  Human  manipulation  degrades  rapidly  with  fatigue  or  time. 

o  Human  manipulation  depends  on  sensory  feedback,  and  is  impaired  if 
sensor  function  is  obstructed.  It  is  impaired  when  other  meaningful 
signals  are  being  received. 

o  Human  manipulation  is  degraded  by  heat  or  cold. 

o  Human  manipulation  is  a  single  channel  capability.  It  is  bandwidth 
limited  to  about  two  control  or  adjust  operations  per  second. 

o  Human  manipulation  has  a  relatively  high  response  latency. 

o  Manipulative  performance  may  degrade  with  time  due  to  boredom, 
distraction,  loss  of  motivation. 

4.17  Sensitivity  -  Informational. 


o  Human  performance  is  vulnerable  to  distracting  signals. 

o  Human  performance  degrades  sharply  when  information  loads  exceed 
capacity.  Humans  become  "confused,"  or  experience  panic. 

o  Humans  are  vulnerable  to  a  wide  range  of  emotional  and  other 
affective  conditions. 

4.18  Sensitivity  -  Physical. 


o  Humans  can  tolerate  only  limited  levels  of  imposed  force, 
o  Humans  are  vulnerable  to  a  wide  range  of  environmental  hazards. 

4.19  Economics. 


o  Human  performance  is  uneconomical  for  any  task  which  can  be  clearly 
procedurallzed ,  and  which  will  be  performed  a  sufficient  number  of 
times  to  Justify  an  automated  solution. 

o  Human  costs  are  typically  underestimated  by  designers.  Real  hourly 
rates  must  be  adjusted  by  a  typical  150%  overhead.  Be  sure  to  consider 
costs  of  training,  organizational  support,  recruitment,  lost  time, 
retirement  and  fringe  benefits. 


o  Where  highly  skilled  or  high  ability  people  are  required,  the 
impact  of  diverting  those  people  from  other  jobs  must  be  considered. 
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